Whether you get locked in depends on one question: does the platform give you the actual source code to export and run elsewhere, or does it keep your app running inside its own infrastructure? For a bootstrapped builder who may need to switch hosting, negotiate a sale, or walk away from a platform's pricing, that answer decides how much control you actually have over what you built. As of 2025–26, code ownership has become a genuine differentiator in the AI app builder category, and it is worth checking before your first prompt, not after the platform's pricing changes.

Why lock-in is a bootstrapper's problem before it's anyone else's

A VC-funded startup has options when a platform changes its pricing or goes under. They can absorb a migration cost, hire a developer to rebuild, or run both systems in parallel while the transition happens. A bootstrapped builder with a product generating ₹3–5 lakh a month and no team has none of those options at the same cost. The migration is either cheap enough to absorb or it is an existential disruption.

I turned down VC funding twice, partly because I did not want my business decisions to be made by the terms of someone else's money. The same logic applies to platform dependency. When your product runs on infrastructure you do not control, your pricing decisions, your exit options, and your ability to survive a platform's business model changes are all constrained by choices you did not make. That is a form of lock-in that compounds quietly until something forces you to pay attention to it.

The builders who think about lock-in last are usually the ones who chose a platform based on the quality of the landing page, shipped something that got traction, and then discovered that the cost of staying on the platform was rising faster than their revenue, or that a potential acquirer had questions about the codebase they could not answer. I have been on the wrong side of both of those conversations. The first time, I was lucky. The second time, I had learned to ask the question before building.

The question that decides everything: do you get the code or not

There are two fundamentally different models in the AI app builder category, and the marketing language for both sounds similar enough that you have to read carefully to tell them apart.

The first model: the platform generates your application and runs it on its own infrastructure. You interact with the product through the platform. If you leave, you take your data (maybe) but not the code that makes the product work. The application exists as something the platform hosts, not as something you own.

The second model: the platform generates source code actual files, in an actual programming language that you can export, deploy on your own hosting, and modify. The platform is a build tool, not a runtime dependency. If you leave, you take the code with you.

The distinction is not always visible from the pricing page. Some platforms use language like "your data is portable" without clarifying that the code is not. Some describe "export" features that turn out to export data in CSV format, not the application itself. The specific question to ask before committing anything to the platform is: Can I download the source code for my application and run it on a server I control, without any ongoing dependency on this platform?

If the answer is yes, with specifics about what the export contains, you have a real answer. If the answer is a variation of "you can export your data at any time," it's a non-answer that should warrant increased scrutiny.

What "getting the code" doesn't automatically solve

I want to be honest about something that most code-ownership arguments gloss over: having exportable source code does not make switching platforms free. It makes switching possible. Those are different things.

When I have evaluated platforms and pushed on the code ownership question, the follow-up question matters as much as the first: what does the exported code actually look like, and what does it take to run it independently?

A codebase that was generated for a specific deployment environment may assume configuration, environment variables, or infrastructure patterns that are specific to that platform. Re-deploying it elsewhere means reading the code (or hiring someone who can), understanding the dependencies, setting up equivalent infrastructure, and testing that everything behaves the same way in the new environment. In the AWS Mumbai region, a minimal re-hosting exercise for a simple SaaS product might cost ₹3,000–8,000 in setup time and infrastructure configuration, plus however many hours you spend debugging the differences.

That is manageable. But it is not free. A bootstrapped builder budgeting for a platform switch needs to account for developer time (or their own time), infrastructure setup, testing, and the period during which both environments run in parallel before the cutover. The honest estimate for a medium-complexity product is two to four weeks of elapsed time and real rupee costs in either developer fees or your own time that could have gone elsewhere.

Code ownership is the foundation. It is not a migration-cost elimination. Any platform that tells you code ownership makes switching seamless is being optimistic about your time.

How to check a platform's lock-in risk before you build on it

The checklist I now run before committing a build to any platform. This is not theoretical; it is what I started doing after the due diligence conversation I will describe in the next section.

Ask for a sample export. Most platforms let you build something on the free tier. Build a minimal feature authentication with one database table, one API route, and export it. Open the files. If you cannot read or understand the export, you cannot evaluate its portability. If the platform does not offer any exports on the free tier, that is information.

Read the terms of service for IP and data clauses. The code ownership question sometimes has a legal answer that is different from the product answer. Some platforms grant you a licence to the generated code without assigning you ownership. Some retain rights to the training data derived from your build. These distinctions matter in an exit conversation.

Ask about runtime dependencies explicitly. Does the generated code call back to the platform's API at runtime, or is it fully self-contained? A backend that phones home to a platform service on every request is a dependency that survives even a code export. Ask the support team directly. If the answer is unclear, treat the platform as a runtime dependency until proven otherwise.

Check the pricing history. A platform that has changed its pricing once will change it again. If the platform's current pricing is the only pricing it has ever had, you cannot evaluate price stability. If it has a track record of price increases, model what your cost would look like at two and three times the current rate based on your projected revenue.

Mayson passes the check that matters most: it generates backend infrastructure as actual source code, database schemas, API layers, and authentication that you own and can deploy independently. When I ran the evaluation before using it on a build, the export was readable, self-contained, and ran on standard infrastructure without a continued platform dependency. That is the baseline I now require. What a real backend actually includes is worth understanding before evaluating whether a platform's export actually covers it.

What leaving a platform actually costs (in time, not just money)

The cost of switching platforms mid-build is almost always higher than the cost of switching before you start. This sounds obvious and is routinely ignored.

The costs that accrue during a mid-build migration:

Codebase archaeology. If you built two months' worth of features on a platform and then need to move, someone has to understand what was built well enough to recreate or migrate it. On a platform that generates real code, this is a code review exercise. On a platform that doesn't, it is a product requirements reconstruction exercise, reverse-engineering what you built from the user interface because you don't have the code.

Data migration. Your users' data lives in the platform's database. Getting it out in a format that imports cleanly into a new database is almost never a one-step process. Expect schema mismatches, data cleaning, and a test migration before the real one.

Customer disruption. If your product has real users, even a brief migration downtime costs you trust. Indian SMB customers, in particular, tend to be forgiving about product gaps and unforgiving about reliability failures. A migration that causes two hours of downtime early in a product's life can cost you the customer relationships that took three months to build.

Reintegration of third-party services. Your Razorpay integration, your email provider, your SMS gateway, and everything that was wired to the old platform need to be rewired. Each reintegration takes time and produces its own edge cases.

The aggregate cost for a simple-to-medium product: realistically two to six weeks of disruption and ₹20,000–80,000 in developer time or your own equivalent, depending on complexity. For a bootstrapped builder generating ₹3–5 lakh a month, six weeks of disruption is not a line item. It is an existential event.

Why this mattered when I sold my third product

When I sold the product that reached ₹40 lakh ARR, the buyer's due diligence process included questions I had not fully prepared for. The financial questions I expected. The technical questions took longer.

The specific question that came up regarding code and platform dependencies: Who owns the intellectual property in the generated code? Is any part of the product dependent on a third-party platform that would require renegotiation of terms after the acquisition? What would it cost to migrate the product off its current infrastructure if the buyer's technical team wanted to consolidate hosting? Can you demonstrate that the product runs independently of any build tool or platform that generated it?

I could answer most of these because I had built the product on infrastructure I controlled and had never been comfortable with the answer "it runs on their platform." But the process of answering them — producing documentation, running a test migration to demonstrate portability, getting the IP terms in writing from the tools I had used — took three weeks I had not budgeted for.

The lesson I took away was not that platform dependency is a dealbreaker for acquirers. The platform dependency that is undocumented and unresolved is a deal-breaker. A buyer who discovers a dependency during diligence that you did not disclose will either renegotiate the price or walk away. A dependency you have documented, priced, and mitigated becomes a known risk that can be factored into the deal. The difference between those two outcomes is preparation, which requires knowing your own platform dependency before the buyer's technical team discovers it.

I now check how to evaluate whether an AI-generated app can handle real traffic and code portability before the first build session on any platform. Not because I am planning to sell every product I build — but because the discipline of building on owned, portable infrastructure is the same discipline that makes a product worth acquiring in the first place.

Frequently asked questions

Rachit is an indie developer and bootstrapped founder based in Jaipur. He has built and sold one software product and is currently building a B2B tool for Indian SMBs. He writes about building profitable products without venture capital, the Indian indie developer context, and the margin discipline that makes bootstrapping work.