WizCodes
WorkAbout
WizCodes

Production-ready web platforms, mobile apps, and AI systems. Based in Ahmedabad, India.

Serving clients in US · UK · Canada · Europe

hello@wizcodes.site
Ahmedabad, India · Est. 2025

Services

ServicesWeb DevelopmentMobile AppsAI AutomationMVP DevelopmentUI/UX DesignHire DevelopersIndustries we servePricingWhat drives the cost

Company

WorkAboutDivya Patel, founderWorking across bordersContact

Resources

BlogComparisonsOpen SourceFAQTestimonials
Listed on
ClutchGoodFirmsThe Manifest
MSME CertifiedDUNS RegisteredGDPR & DPDP256-bit TLS100% code ownership
© 2026 WizCodes. All rights reserved.Ahmedabad, India — Global Clients
Privacy·Terms
  1. Home/
  2. Blog/
  3. Own your code: what agency lock-in really costs you

Own your code: what agency lock-in really costs you

Their servers, their accounts, "we will handle that for you" — the small conveniences that trap you, and how to keep ownership from day one.

By the WizCodes team·June 19, 2026·6 min readOwnershipProcess
Side-by-side comparison: Quiet lock-in versus Real ownership. From the WizCodes article "Own your code: what agency lock-in really costs you" — Ownership.

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.

Key takeaways

  • Lock-in is built from small conveniences, not from bad intentions.
  • If an asset is not in your name, you do not own it. Access is not ownership.
  • The cost stays invisible while things go well, and appears the moment you need to move.
  • Real ownership has to be arranged on purpose, at the start. It is not hard.
  • Three questions before you sign will tell you everything about a vendor.

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 same finished project, handed over two different ways. Quiet lock-in: Their hosting account, Their developer account, Domain in their name, Code you can access only. Real ownership: Your hosting account, Your store accounts, Domain in your name, Code in your repository.
The same finished project, handed over two different ways

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.

Access is not ownership

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 four things that have to be in your name for you to own your product. Steps: 1. Repository; 2. Hosting; 3. Store accounts; 4. Services.
The four things that have to be in your name for you to own your product

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.

Decision: Is your source code in a repository you own? If yes, My own account: Good. Now check hosting, stores and the domain.. If no, Their account: Start here. A repository transfer is one click..
Where to start if your project is already running on someone else's accounts

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.

Frequently asked questions

Why is agency lock-in a problem if the work is good?

Because it changes every future conversation. Your costs are set by someone else's pricing, moving to a new team depends on their cooperation, and both sides know what leaving would cost you. The work being good does not change any of that. It only delays the moment you notice.

How do I keep full ownership of my software?

Set it up deliberately from day one. The code in your repository with the vendor as a collaborator, deployment to your hosting account, apps submitted to your own App Store and Play Store accounts, and every third-party service registered in your name. None of it is difficult, but it has to be arranged rather than assumed.

What should I ask a vendor before signing?

Three things. Whose accounts will the code, hosting and store listings live under? On the day this ends, what do I walk away with and how? Are the domain and third-party services in my name or theirs? Plain answers are a good sign. Vague answers are an answer too.

Does keeping ownership cost more?

It should not. Delivering to your own accounts is a choice about how a studio works, not a premium feature. We do it as the default on every project, because we would rather be kept for the work than for the hostages.

My project is already built on their accounts. What now?

List what exists and whose name each thing is in, then move the cheapest items first. Domain transfers take minutes and repository transfers take one click. Hosting is harder but usually manageable. Store accounts need the most care, so start that conversation early and while the relationship is still good.

Is it rude to ask for ownership up front?

No, and a good vendor will read it as a sign you think ahead. It is a normal commercial question, in the same category as asking about timelines or payment terms. The only people it makes uncomfortable are the ones you most need to ask.

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.

Want a build where ownership is never a question?

Everything we build is delivered to your own accounts and repositories from the first commit. Tell us what you are building and we will design a free prototype first.

Get a free prototype

What we build around this

  • Hire developers
  • How pricing works