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.
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:
|
Where it happens |
What holds you there |
Example a founder would recognize |
|
Cloud hosting |
Services that exist on only 1 provider, and the work of moving data |
A product built on 1 provider's database and serverless functions |
|
SaaS tools |
Your data in a format that does not export cleanly |
Customer records in a CRM with a limited export |
|
No-code and AI app builders |
The app runs only on the builder's platform |
An app you cannot take with you if the platform shuts down |
|
AI models |
Prompts, features, and workflows tuned to 1 provider's model |
A support chatbot built around 1 model's API |
|
Your development vendor |
Code, accounts, and knowledge held by the team that built the product |
The repository and App Store listing are under the agency's name |
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.
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.
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.
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:
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:
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.
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:
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.
|
Usually a fair trade at MVP stage |
Worth avoiding from day 1 |
|
A mainstream cloud provider, in your company's account |
Hosting in the vendor's account |
|
A payment platform, in your company's name |
A payment account registered to the vendor |
|
An agency's reusable components, with a license your next team can use |
An agency's closed framework with no license for other teams |
|
A no-code tool that exports code or data |
A no-code tool that exports neither |
|
1 AI model provider, called from 1 place in the code |
Calls to 1 AI provider spread through the whole product |
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.
|
Stage |
What to do |
Done when |
|
Before you sign |
Put an IP assignment clause in the contract, covering the vendor's own developers |
The clause is signed, and the vendor confirms its developer contracts match |
|
Before you sign |
Ask which reused components or in-house tools the vendor will use |
You have a list and a license for each |
|
Before you sign |
Agree on exit terms: a handover period, documentation, and help onboarding the next team |
Exit terms are in the contract |
|
Week 1 |
Create the repository, cloud, domain, app store, and other accounts yourself, then invite the team |
You are the owner and the payer on every account |
|
During the build |
Ask for a README and a short decision log, updated each sprint |
A new developer could set up the project from them |
|
During the build |
Make sure more than 1 person on the team knows each critical part |
No single person holds knowledge the rest of the team lacks |
|
During the build |
For closed tools and AI providers, write down the exit cost |
A 1-page note: what we would rebuild and how long it would take |
|
Every 6 months |
Run a small handover test: can someone outside the team deploy a release from the docs? |
The test passes, or the gaps are on the backlog |
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.
If you recognized your project in the 4 layers, take these steps in order, even when the first ones feel slow.
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.
Sproutly sits between you and your development partner, so a fair question is whether our model creates lock-in of its own.
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.
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.
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.
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.
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.
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.