Lock-in almost never arrives as a decision. Nobody signs a contract saying "you will depend on us forever."
It arrives as small favours. Each one is genuinely helpful at the time. Then one day you want to hire your own team, change vendors, or simply understand what you own, and the answer turns out to be less than you assumed.
Here is how it happens, and how to prevent it without being difficult about it.
How does lock-in actually happen?
Four sentences do most of the damage. Each one sounds like a favour.
"We will host it for you." Your product now lives on infrastructure you cannot reach, under an account that is not yours. Moving it means asking permission.
"We will submit the app on our developer account." Your app is published under someone else's name. The listing, the reviews and the users are legally theirs.
"Do not worry about the domain and services, we set all that up." The keys to your product now sit in someone else's drawer.
"The code is on our repository. We will give you access." Access is not ownership. Access can be revoked, and "we will send it over" has a way of turning into a negotiation.
None of this needs bad intentions to hurt you. A vendor can be completely honest and you can still be unable to leave, because the assets were never in your name.
The work can be identical in both columns. What differs is whose name is on it.
Why does it matter if the work is good?
Because three things quietly become true, and none of them are about the quality of the code.
Your costs stop being yours to control. They are set by someone else's pricing and goodwill. Both can change.
Your ability to move depends on their cooperation. Changing vendors, hiring in-house, or pivoting all become negotiations rather than decisions.
Your leverage disappears. In every future conversation, both sides know what walking away would cost you. That knowledge shapes every price and every timeline you are offered.
The cruel part is the timing. Lock-in costs nothing while the relationship is good. It appears at the exact moment you need flexibility most: a pricing dispute, a pivot, a disagreement, or simply growing enough to want your own team.
If your code sits in a repository owned by someone else and you have been added to it, you have permission, not property. Permission can be withdrawn. Ownership cannot.
What does real ownership look like?
It is not complicated. It just has to be set up deliberately, at the start, rather than fixed later.
The repository is yours, with the vendor added as a collaborator. That is a relationship you can end at any time, rather than one you have to exit.
Deployment goes to your hosting account. Servers, database and domain are all set up under credentials you hold.
Apps are submitted to your own store accounts. Your developer account, your listing, your reviews, your users.
Every third-party service is in your name. Payments, email, analytics, error tracking. You hold the keys.
Do this and the vendor relationship becomes what it should be: worth keeping because of the work, not because of what they are holding.
What if it is already too late?
It usually is not, but the longer you wait the more it costs.
Start by writing down what exists and whose name each thing is in. Most founders have never made this list, and making it is often the moment the problem becomes real.
Then move the cheapest things first. A domain transfer takes minutes. A repository transfer takes one click and a confirmation. Those two alone remove a surprising amount of risk.
Hosting is harder but rarely as hard as feared, especially if the project was built to standard practices. App store accounts are the most painful, because a published app cannot simply be moved between developer accounts without care. Start that conversation early and calmly.
Do this while the relationship is good. Asking for your own assets is a normal request from a happy client and a confrontation from an unhappy one. The paperwork is the same; the conversation is not.
What should you ask before you sign?
Three questions. You do not need to be confrontational, just clear.
Whose accounts will the code, the hosting and the store listings live under? The answer should be yours, without hesitation or conditions.
On the day this ends, what exactly do I walk away with, and how? A good vendor has thought about this and can describe it in a minute.
Are the domain and third-party services registered in my name or yours? This is the one people forget, and it is the one that bites hardest.
A good partner answers all three plainly and is pleased you asked, because it means you plan ahead. A vendor who becomes vague has just answered a different, more useful question for you.
Why we deliver this way by default
We deliver every project end-to-end to your own accounts. Designed, built, tested, deployed, and submitted to your hosting and store accounts.
You own all of it from the first commit. It is not an upgrade or a parting gift, and there is no version of our work where it is not true.
The reason is straightforward. We would rather keep clients by being worth keeping than by holding their infrastructure. A client who can leave at any time and chooses not to is a better relationship than a client who cannot.
It also makes our quotes simpler. When there is no hosting to resell and no lock-in to protect, the price is just the work, which is how we prefer to price.
The short version
Nobody sets out to trap you. Lock-in is built from small conveniences, and it costs nothing until the day you need to move.
Put the repository, the hosting, the store accounts and the services in your name at the start. It takes very little effort on day one and it is the difference between a vendor you choose to keep and one you have to.
