The short version: vibe-coding platforms let a non-technical founder ship real software from a prompt — and the good ones now let you keep the code. Lovable, Bolt, and Emergent (a unicorn as of July 15, 2026) all advertise full code ownership with GitHub sync. The catch is that "you own the code" is a claim, and the only version of it that matters is whether a git clone of your repo builds and runs on a machine the vendor does not control. Below is the six-check ownership test to run before you bet your company on one — not after.

The reason this matters right now: Emergent just raised a $130M Series C at a $1.5-billion valuation, roughly thirteen months after launch, explicitly to help entrepreneurs and small businesses "build the software their businesses run on." That is capital betting that your next internal tool, client portal, or MVP comes from a prompt instead of a hire. The leverage is real. The discipline is making sure it does not come with a leash.

1. Can you export a real repository — today?#

Not a downloadable ZIP of minified output. A working Git repository with source files, a dependency manifest, and a commit history you control. Lovable describes a two-way GitHub sync where "your code lives in your repository, not locked in Lovable"; Bolt lets you "export the full code, sync with GitHub, and host apps anywhere"; Emergent says you keep full ownership and can push and pull from VS Code and GitHub. Do this first, on day one, before you build anything real: connect the platform to a repo you own and confirm the code actually lands there. If export is download-only or gated behind a higher tier, treat that as the answer.

2. Does the exported app build and run off-platform?#

Ownership is theoretical until you prove it. Clone the repo to a clean machine, install dependencies, set the environment variables, and run it — with the platform tab closed. If it boots, you have a real exit path. If it only runs inside the vendor's hosted runtime because of undocumented services or magic environment glue, you do not own an app; you own a description of one. This ten-minute test is the single most important thing on this list.

3. Where does your data actually live?#

Most prompt-to-app platforms provision a database and auth for you, which is the convenience — and the trap. Find out whether that database is yours (a Postgres you can get a connection string to and dump) or an opaque platform store you can only reach through their UI. Customer data with no export path is a second, quieter form of lock-in that survives even if you keep the code. Point the app at storage you can back up and migrate.

An exportable repo you can self-host turns "the platform got acquired" from an existential event into an afternoon of migration.

4. Price the app at 10x today's usage#

The subscription that feels free at demo scale is not the number that matters. Model the cost at ten times your current usage — more seats, more API calls, more generated-code regeneration cycles — and compare it against a one-time contractor build plus cheap hosting. Watch specifically for credit systems that can be repriced and usage meters you cannot forecast. If the only place the app runs is the vendor's runtime, a mid-contract price change is one you cannot refuse. Portability (checks 1–3) is what gives you the leverage to walk.

5. Read the termination and IP clauses#

Before you build the thing your business runs on, read the two paragraphs everyone skips: what happens to your code and data if you cancel or the account is terminated, and who holds the IP to what the model generates. "You own the code" in the marketing copy and "we grant you a revocable license" in the terms are very different sentences. You want the repo and the IP to be unambiguously yours on the way out.

6. Security-review the generated code before it faces a customer#

Treat generated code the way you would treat fast, cheap contractor work: mostly right, occasionally dangerous, and never trusted with production defaults. The platform wired up auth, secrets, and access control to satisfy a prompt, not an attacker — so that wiring is exactly where you get burned. Add real authentication, move secrets out of the source, check row-level access, and run a scan before anything customer-facing ships. We wrote the full list in the vibe-coded app maintenance and security checklist.

Do this before you commit: run checks 1 and 2 — export a repo and boot it off-platform — on any tool you are evaluating, this week, before you write a line of real product. A platform that passes gives you all the leverage of a prompt and none of the leash. One that fails just told you it plans to keep your business inside its walls. If you are still choosing, our Emergent vs Lovable vs Replit breakdown maps the leaders against exactly these criteria.