What is vendor lock-in, and how to avoid it with an outsourced team

You want a second opinion on a quote, so you ask another development firm to look at the code. They send back 1 request: access to the repository.

You go looking. The repository sits in your developer's GitHub organization. The hosting account, the domain, and the App Store listing are registered to their company too.

Nothing is wrong yet. Your team still ships every sprint. But if you wanted to leave, you would have to ask them for everything.

That is vendor lock-in. In outsourced software projects, it usually builds up quietly, 1 convenient default at a time.

When someone else builds your product, lock-in hides in 4 places, and you can check all 4 this month with the checklist below. If you are already locked in, there is an order of steps that gets you out without breaking the product.

What vendor lock-in means in practice

Every supplier relationship carries switching costs: the money, time, and risk of moving to someone else. Some are small, like exporting a spreadsheet. Some are large, like rewriting a product that only runs on one company's tools.

Lock-in starts when those costs grow larger than the pain of staying. At that point, staying becomes the default, whether or not it is still the best option.

Here are the vendor lock-in examples a founder is most likely to meet:

The last row is the hardest to spot, because nothing breaks until you try to leave. The 4 layers below all sit in that row.

Large organizations worry about this too. In Parallels' 2026 survey of 540 IT professionals in the US, the UK, and Germany, 94% of organizations said they were concerned about vendor lock-in.

How vendor lock-in builds when someone else builds your product

When an outside team builds your product, lock-in rarely starts as a plan. It grows out of small decisions made for speed in the first weeks, and it settles into 4 layers: the contract, the accounts, the knowledge, and the technology.

1. The contract: who legally owns the code

What it looks like. Your contract calls the work "work made for hire," or it says nothing about ownership. Some of the people writing your code are freelancers working for your vendor, and you have never seen their contracts.

Why it happens. Under US copyright law, the person who writes the code owns it until something moves the rights. Work by an outside contractor counts as a work made for hire only if it falls into 1 of 9 categories of commissioned work listed in the Copyright Act, and software is not among them (17 U.S.C. §101; US Copyright Office, Circular 30). For software, ownership moves through a written assignment signed by the owner (17 U.S.C. §204).

So a contract that only says "work for hire" may leave the copyright with whoever wrote the code.

Outsourcing adds a second link to the chain. Your vendor can only assign rights it holds, so its contracts with its own developers, including freelancers and staff in other countries, have to assign their work to the vendor first. If you are still deciding where your team should sit, see how to choose an outsourcing model.

Agencies also reuse their own building blocks: login systems, admin panels, internal frameworks. Keeping the rights to those is common and fair, as long as your license lets a different team keep using them after you part ways.

The check. Ask: "Does my contract assign all rights in the code, designs, and documentation to my company, and do the vendor's contracts with its developers do the same?" A good answer is a yes you can point to in writing, plus a list of reused components and a license that lets another team keep working with them.

This section is general information about US law. For advice on your own agreement, ask a startup attorney to review it, especially if your vendor is based outside the US.

2. The accounts: who holds the keys

What it looks like. The code repository, cloud hosting, domain, app store developer accounts, analytics, email service, and payment provider were all set up under the vendor's company. You were invited as a user, and the invoices go to them.

Why it happens. In week 1, speed wins. The vendor already has a GitHub organization, a cloud account, and an Apple developer account, so adding your project takes minutes. Creating new accounts in your company's name can take days of verification. Planning the exit is rarely on the kickoff agenda.

Each account is a small convenience. Together, they mean you cannot release an update, renew a domain, or publish a new app version without the vendor's help.

Moving them later takes cooperation. On Apple's App Store, for example, the Account Holder of the current developer account starts an app transfer, and the Account Holder of the receiving account accepts it.

The check. Ask: "Am I the owner on every account my product needs to run, and does the bill come to my company?" Billing in your name is part of ownership.

Our list of the accounts you should own covers the basics: repository, hosting, domain, app store accounts, task board, and password manager. Add these too:

• Third-party API keys for maps, SMS, and email delivery. If the keys sit in the vendor's accounts, those features stop working when the vendor closes them.
• AI provider accounts. If your product calls an AI model, the API account, its usage history, and its billing should be in your company's name.
• The payment provider account. Your customers' saved payment details live there, so it belongs to your company from the first transaction.

3. The knowledge: what is written down

What it looks like. 1 developer knows how the payment flow works. Architecture decisions live in old chat threads. There is no setup guide, so a new team would spend weeks getting the product to run on their own machines.

Why it happens. Documentation feels like overhead when the same team will keep working on the product next month. So knowledge settles in a few heads.

Engineers call this risk the bus factor: the number of people who would have to leave before a project stalls. If 1 developer holds the payment logic, your bus factor for payments is 1.

This layer is easy to miss because no contract covers it. You can own every line of code and every account and still be unable to change a pricing rule without the person who wrote it.

The check. Ask: "Could a new team set up, build, and deploy the product using only what is written down?" A good answer comes as 3 documents:

• a README that a new developer can follow to run the product and release a new version
• a short decision log: the major technical choices, when they were made, and why
• a list of third-party services, with what each one does, who pays for it, and where its keys are stored

4. The technology: how much depends on 1 vendor's closed tools

What it looks like. Your product runs on the agency's in-house framework, lives on a no-code platform that cannot export its code, or has AI features that call 1 model provider directly from dozens of places in the code.

Why it happens. Each of these choices can be sensible. An in-house framework speeds up the first release, a no-code tool can save months, and calling 1 AI provider directly is the fastest way to ship a feature. They turn into lock-in when no one priced the exit.

Larger companies are learning this with AI. In Zapier's 2026 survey of 542 US executives at companies with paid AI contracts, 74% said losing their main AI vendor would disrupt operations or leave them unable to function. Only 6% said they could stop using it without disruption. The sample is enterprise, but the mechanics are the same for a startup with 1 AI feature.

Some teams respond by choosing open source. In OpenLogic's 2026 State of Open Source Report, 55% of organizations named avoiding vendor lock-in as a reason to choose open source software, up from 33% a year earlier.

Platforms can also fail. In May 2025, Builder.ai, a Microsoft-backed app development platform that had raised more than $450 million, entered insolvency proceedings (TechCrunch). Customers whose apps ran on its platform had to work out what they could recover.

The check. Ask: "If this tool or vendor disappeared, what would we rebuild, and roughly how long would it take?" Ask your team to answer in writing. 1 page is enough.

The cheapest moment to answer it is before the build approach is set. See how to scope an MVP for that decision.

When some lock-in is a fair trade

Accepting some lock-in is often the right call for an early product. A major cloud provider, a payment platform, or a no-code tool can save you months, and an MVP exists to learn quickly.

A trade is fair when 3 things are true:

• You can name the exit cost: what you would rebuild and roughly how long it would take.
• The cost is written down, somewhere your current team and the next one can find it.
• The contract, accounts, and documentation are in your name, so the choice to stay or leave stays yours.

When all 3 hold, the lock-in is a decision you made at a price you know. Good moments to reopen it are the next funding round and the point where version 2 needs something the tool cannot do.

How to avoid vendor lock-in: a checklist for founders

Most of the work happens before you sign and in the first week. After that, keeping the exit open takes a few minutes per sprint.

What about code escrow? In a source code escrow arrangement, a neutral third party holds a copy of the code and releases it to you when agreed conditions occur, typically the vendor's bankruptcy or its failure to maintain the software as the contract requires. Escrow matters most when the vendor hosts the product or licenses it to you. If you already own the repository, it adds little.

Already locked in? How to get out without breaking the product

If you recognized your project in the 4 layers, take these steps in order, even when the first ones feel slow.

1. Keep the current team for now. Do not fire anyone yet. Leaving before you have access and documentation is how products get stranded.
2. Ask for owner access to every account. Present it as a standard request, the kind an investor or acquirer would expect. A good vendor will agree, and most do.
3. Get the code and a written inventory. List the repositories, environments, third-party services, credentials, and who on the team knows which part.
4. Get an independent read of where you stand. Someone outside your vendor reviews the code, the documentation, and how hard a handover would be.
5. Plan an overlap period. For a few weeks, the old and new teams work side by side, with the old team paid to hand over.
6. Check the contract before the final step. Look at the IP assignment, any reused components, and the termination terms. Bring in an attorney here if needed.

Tow Ninja, a towing app, came to Sproutly with a partial MVP from a previous developer. Sproutly reviewed the code, fixed the priority issues, added automated testing and a release pipeline, built the missing features, and helped launch the pilot in Harrisonburg, VA. Read how we finished a build another team started.

Handovers like this one go faster when the code, accounts, and documentation already sit in the founder's name.

If you want that outside read on your own project, schedule a team assessment. You will get a plain-language view of what you own, what is missing, and what a handover would take, whether you keep your current team or not.

How Sproutly keeps you free to leave

Sproutly sits between you and your development partner, so a fair question is whether our model creates lock-in of its own.

1. Under Edge Sourcing™, whose name the repository, cloud, domain, and app store accounts are set up under.
2. Whether the client's contract assigns IP directly to the client, and whether partners' contracts with their own developers assign to the partner.
3. What happens if a client keeps the development partner and stops working with Sproutly, or the reverse.
4. What documentation Sproutly and its partners deliver as standard.
5. Whether the school district and its development partner can be named.

References

1. US Copyright Office (2024). Circular 30: Works Made for Hire. Revised August 2024. copyright.gov
2. 17 U.S.C. §101, Definitions ("work made for hire"). Cornell LII
3. 17 U.S.C. §204, Execution of transfers of copyright ownership. Cornell LII
4. Community for Creative Non-Violence v. Reid, 490 U.S. 730 (1989). Justia
5. Apple. "Overview of app transfer." App Store Connect Help. Apple Developer
6. Parallels (February 17, 2026). 2026 State of Cloud Computing Survey. Press release. Parallels
7. Flanigan, R. (April 1, 2026). "Nearly 3 in 4 enterprises say losing AI vendors would disrupt core business operations." Zapier. Zapier
8. Weier O'Phinney, M. (March 31, 2026). "2026 State of Open Source Report: Top Takeaways." OpenLogic by Perforce, with the Open Source Initiative and the Eclipse Foundation. OpenLogic
9. Silberling, A. (May 20, 2025). "Once worth over $1B, Microsoft-backed Builder.ai is running out of money." TechCrunch. TechCrunch
10. Codekeeper. "Software escrow release conditions: A practical guide." Codekeeper
11. Regulation (EU) 2023/2854 (Data Act), Article 29. EUR-Lex

FAQ

Is vendor lock-in always bad?

Vendor lock-in becomes a problem when you cannot name the exit cost, or when the contract, accounts, and documentation are not in your name. Some lock-in buys real speed: a mainstream cloud provider or a payment platform can save an early product months. The test is whether you know what leaving would cost and can still choose to pay it.

What is an example of vendor lock-in?

A common example for founders is a product whose code repository and App Store listing sit under the development agency's name, so the founder cannot release an update or move to a new team without the agency's help. A cloud example is a product built on 1 provider's database and serverless functions, where moving means rewriting those parts.

Do I own the code my outsourced developer writes?

Under US law, you own code written by an outside developer only when a signed, written agreement assigns the copyright to your company. Calling the work "made for hire" may not be enough, because software is not one of the 9 categories of commissioned work that qualify. This is general information, so ask a startup attorney to review your agreement.

What is source code escrow, and do I need it?

Source code escrow is an arrangement where a neutral third party holds a copy of a vendor's code and releases it to you if agreed conditions occur, such as the vendor's bankruptcy. It is most useful when the vendor hosts or licenses the product to you. If you already own the repository and the accounts, escrow adds little.

How do I switch development teams without losing my product?

Switch in a set order: get owner access to every account, then the code and a written inventory, then an independent assessment of what a handover would take. Keep the current team until the new one can run the product, and pay for an overlap period of a few weeks. The full sequence is in the "Already locked in?" section above.

Can AI tools or no-code platforms cause vendor lock-in?

AI tools and no-code platforms cause vendor lock-in when your app or your data cannot leave the platform. When Builder.ai, an app development platform that had raised more than $450 million, entered insolvency proceedings in May 2025, its customers had to work out what they could recover. Before you build, check that the platform exports both code and data.