Code export vs no-code lock-in: the six layers of an app you can lose, and what each costs to take with you

1. If the vendor disappeared tomorrow, what would still run? Answer per layer: the code (is it a project in a standard language, or a description the platform interprets?), the data (can you export every table today?), the backend (auth, functions, hosting — where?), the builds (can the app be compiled without the vendor’s servers?). A builder that scores “nothing” on every layer is a rental.

2. Who is the publisher of record? The App Store listing and the Play listing belong to a developer account. If that account is yours ($99 a year for Apple, a one-time $25 for Google), the app, its reviews and its install base stay yours whatever happens to the builder. If it is the vendor’s, leaving means a transfer — both stores have a transfer process, with conditions on their own pages — or a new listing with zero history. Apple Developer account setup is the page for opening yours first.

3. What happens to the price when the app succeeds? Usage-based pricing (credits, tokens, per-request AI, per-user seats that multiply with a team) is not lock-in on day one; it is lock-in on the day the app has users and every change costs more than it did. Compute the monthly cost at the twelfth month of your forecast, not at zero, and ask whether the same work could move to a different tool or a contractor at that point.

The table below scores builder categories, not products, on what you leave with. Individual vendors move between rows as they add features; the per-vendor facts, with the plan and the read date, are on AI app builder code export.

Best case: a project in the platform’s own language — Swift and SwiftUI for iPhone, Kotlin and Jetpack Compose for Android — on your disk, that opens in Xcode and Android Studio. Any contractor can quote on it; Apple’s and Google’s tooling builds it. Middle case: a React Native or Flutter project, which is real source code in a standard framework; the hire is a React Native or Flutter developer, and the project still needs the framework’s toolchain. Worst case: a proprietary description the platform interprets at runtime, with no export, or an export that is a bundle only the vendor’s servers can build. The question that settles the layer: “Can I open the exported project in Xcode or Android Studio and run it, without your servers?” — and on which plan, because several builders export only on paid tiers. The architecture question behind this layer — native vs cross-platform vs wrapper — is on native vs cross-platform app.

Best case: the database is a standard service you hold the keys to (Postgres on Supabase or your own host), with a full export in a standard format available today, and the schema documented. Middle case: the builder hosts the data but exports it as CSV or JSON per table, on demand. Worst case: data lives inside the platform in its own structure, exportable only through the UI, table by table, or not at all. The exit cost is the migration of every user record and every relation, plus the user accounts, which often cannot be moved between auth providers and then force every user to reset a password. The question: “Show me a full export of my data, now, in a format another database imports.”

A mobile app is a client; something answers it. If the builder’s backend is a named third-party service under your own account (Supabase, Firebase, your own server), the app can be rebuilt against the same backend and users never notice. If the auth, the serverless functions and the hosting are the platform’s own, leaving means re-implementing them and re-authenticating every user. The question: “Whose account is the backend in, and can I point a different client at it?”

An iOS build must be signed with your certificates and profiles and produced by Xcode; an Android build is signed with your keystore. Best case: the builds happen on your Mac, with your certificates, or in a CI you control, and the signing keys are yours. Worst case: builds happen only on the vendor’s servers, with signing material the vendor holds; if the vendor stops, so do your updates. Losing the Android upload key or the Apple signing identity is a separate, avoidable disaster: hold them yourself. The question: “Can I produce a signed build without your service, and do I hold the keys?”

The layer people discover last. If the app is published from the vendor’s developer account, the vendor is the publisher; the ratings, the reviews, the install base and the subscriptions are attached to that listing. Both stores allow an app to be transferred between developer accounts, under conditions each store publishes; a transfer that cannot meet them means a new listing and a new history. Best case: your own Apple Developer Program membership and your own Google Play Console from day one, with the builder uploading to them. The question: “Is the app published under my account, and does your tool upload to it?”

Credits, tokens and per-request AI fees scale with success; per-seat pricing scales with the team; a “free until X revenue, then a percentage” model takes a share of exactly the outcome you wanted. None of these are lock-in while the app is small. They become lock-in when leaving would cost more than paying, which is the point at which the vendor sets the price. Best case: a flat price that does not move with usage, and the AI cost on a subscription you already hold, so a bigger app does not mean a bigger bill from the builder. The question: “What do I pay in month twelve at my forecast, and what does it cost to stop?”

Validating an idea in a week, no launch planned: lock-in is irrelevant; take the fastest tool and accept that the prototype is disposable. Keep the spec (the PRD prompt) — that is the asset that survives.

Shipping to the stores, one person, expecting to iterate for a year: layers 5 and 4 first (your own store accounts, your own signing keys), then layer 2 (data you can export today). Code export matters the day you hire; put it third, but check it before you start.

A product with a team, or one you may sell: all six. An acquirer’s technical due diligence asks exactly these questions, in this order, and a “no” on layers 1–3 is a discount on the price.

Already inside a platform with a “no way of exporting” answer: the exit is a rebuild from the spec, not a migration of the code — the data and the backend are what you carry over. Migrating a Lovable app to a mobile app is the worked example of that route; export code from Lovable is what a web-builder export actually contains.

The native-on-both-platforms case: in Modaal the six layers read as follows. Code: the Xcode project and the Android Studio project are on your disk from the first feature, on every plan including Free. Data and backend: your own services under your own accounts (the app is a native client; the builder does not host your backend). Builds: on your Mac, with your certificates. Store: your own accounts; TestFlight distribution on Pro. Pricing: the AI runs on the subscription you already have, unlimited prompts; the Free plan covers one project on one platform, and Pro is €9 per user per month billed annually, €15 monthly, adding both platforms, TestFlight and Git collaboration — /pricing.