Why “zero lock-in” matters
AI app builders can get you to a working prototype fast. The risk is what happens after the prototype, when you need to change models, add integrations, control costs, or move the app to your own infrastructure.
Lock-in is not just inconvenience. It is a set of technical and business constraints that make leaving expensive enough that you stop considering it.
What lock-in looks like in AI app builders
Code that you cannot take with you
Some cloud builders do not give you the full project as normal source code, or they only let you view code inside their UI.
Common symptoms:
- No Git repo you can clone.
- No local dev server you can run.
- Export exists, but it is incomplete or read-only.
Proprietary project formats
Even when an export exists, it may rely on a custom runtime, custom components, or platform-only services.
This is lock-in because “export” does not mean “portable”.
Single-model dependency
If the platform only supports one provider or one model family, you inherit that provider’s:
- pricing changes
- rate limits
- outages
- model behavior changes
If model quality shifts after an update, you may have no rollback path.
Data and workflow entanglement
Projects often depend on platform features that do not migrate cleanly:
- hosted databases and auth tied to your account
- logs, evals, prompt history, and versions stored only in the vendor UI
- background jobs, webhooks, and secrets management implemented as platform features
When you leave, you lose more than code. You lose operational context.
The costs that do not show up on the pricing page
The rebuild tax
If you cannot export a standard codebase, switching tools becomes a rewrite. The cost is not only engineering time. It is also:
- delayed roadmap
- lost momentum
- churn risk while the rewrite happens
Pricing leverage disappears
Once leaving is expensive, price increases are hard to avoid. You are paying for switching costs, not just product value.
You miss model improvements
The model ecosystem moves fast. If your builder is slow to add providers, you cannot use:
- cheaper models for high-volume tasks
- specialized models for coding, vision, or long context
- local models for privacy or cost control
Shutdown and acquisition risk
If the platform changes direction, sunsets features, or shuts down, your app becomes an emergency migration.
Keep in mind that even “stable” tools can change terms, limits, or supported models.
What “zero lock-in” looks like in practice
“Zero lock-in” is not a slogan. It is a set of properties you can verify.
Local-first development
You can run the project on your machine. You can open the code in your editor. You can commit it to Git. If the tool disappears, your project still runs.
Open-source foundation
You can inspect how the tool works and what it sends to model providers. If development slows down, you can fork or rely on the community.
Trade-off: open-source does not guarantee long-term maintenance. It does give you options.
Model flexibility
You can choose providers and models based on your constraints:
- quality for a specific task
- cost per token
- latency
- privacy requirements (including local models)
Standard, recognizable code output
The project is a normal codebase using common tools and frameworks. You can deploy it without a special platform runtime.
Export is not a feature, it is the default
You do not need a special button, approval, or paid tier to take your code elsewhere. The code is already yours.
A checklist to evaluate any AI app builder
Ask these before you commit real time.
-
Can I run the generated app locally?
If not, you are depending on their runtime. -
Do I get a real repo with normal files?
Look for a standard folder structure, package manager, and scripts you can run. -
What happens when I cancel?
Can you still access the code and data? Can you still run the app? -
Which models and providers are supported today?
Also ask how you bring your own keys, and whether you can route different features to different models. -
What parts of the app depend on platform-only services?
Auth, database, storage, jobs, analytics, secrets, and deployments are the usual traps. -
Can I deploy outside their platform?
Ask for a concrete deployment path, not a promise.
Where Dyad fits
Dyad is a local, open-source AI app builder. It runs on your machine, so your source code and project data stay local by default. You can use different AI models and providers, and the output is a normal codebase you can edit and deploy without a proprietary runtime.
Trade-offs to keep in mind:
- You need to run the dev environment locally (Node.js and the usual tooling).
- You manage your own deployment and hosting choices, instead of relying on a fully managed cloud builder.
If you are not sure, I recommend using a cloud builder for a throwaway prototype, then switching to a local-first workflow before you accumulate months of product work in a platform you cannot leave.
