Runtime Lock-In and Self-Host Depth: A Proposed Axis for Whether AI-Builder Apps Actually Run Off-Platform (August 2026)

Quick answer (August 2026). Runtime lock-in and self-host depth measures whether the code an AI app builder emits can actually build, run, and be self-hosted away from the vendor's platform. It is the gap between two very different promises: "you can export your code" and "your exported code will run somewhere else." A builder can honestly offer the first and still fail the second, because the code it hands you may expect a managed database, a proprietary auth service, or a runtime that only exists inside the vendor's cloud. This is a proposed BuilderProof axis, not a scored leaderboard. Like every BuilderProof axis it is designed to cover all five commercial builders we track (Bolt, v0, Lovable, Replit, Base44), be reproducible from published rules, and stay open to public revision. Below is the six-signal rubric we propose to score it with.

Why "you can export the code" is not the whole answer

The most common reassurance in this category is code export. It is a real and valuable feature, and we already track a related question in our code ownership and portability leaderboard: do you get the source, under what license, and how idiomatic is it? A separate axis, code portability, asks whether that source reads like a standard project a human could maintain.

Runtime lock-in asks a third, downstream question that neither of those settles: once you have the code, does it stand on its own? An export is only an escape hatch if what comes through the hatch can start without the platform you are trying to leave. In practice the failure is quiet. The zip downloads. The repository syncs to GitHub. Then you run the install and build on your own machine, and the app boots into a wall of missing environment variables, a client pointed at a hostname you do not control, or a server call to an endpoint that only answers inside the vendor's account. The demo worked. The eject did not.

This is a specific, testable form of vendor lock-in. It is worth isolating because it is the one most likely to be discovered late, after a team has already committed, when switching cost is highest.

The principle we score against

We borrow the yardstick from the Twelve-Factor App's backing services factor: "The code for a twelve-factor app makes no distinction between local and third party services." In a clean design, the database, the object store, the auth provider, and the mail service are attached resources reached through configuration. Swapping a managed database for one you run yourself should be a config change, not a rewrite.

That gives us a concrete test for generated apps. If a builder emits code where the backend is reachable only through a hardcoded, vendor-specific path, self-hosting means rewriting. If it emits code where those services are attached through configuration, self-hosting means editing a config file and pointing at your own infrastructure. The distance between those two outcomes is exactly what this axis is trying to measure.

We anchor the "runnable off-platform" end of the scale on documented, standard deployment. A Node-based app, for example, is self-hostable in the ordinary sense when npm run build then npm run start produces a working server on your own host, per the framework's own deployment guidance (Node server, Docker container, or static export). No proprietary wrapper required.

The six signals

We propose scoring runtime lock-in from six independent signals, each observable and each reproducible from published evidence.

1. Runtime dependency. Does the emitted code import or call vendor-only runtime APIs, SDKs, or edge functions that have no off-platform equivalent? A hard dependency here caps the score regardless of anything else, because the code cannot even build cleanly outside the platform.

2. Backend self-hostability. Can the app's stateful services (authentication, database, file storage, server functions) be repointed at self-hosted or standard third-party equivalents through configuration alone, in the backing-services sense above? Or is the backend a managed service with no self-host path?

3. Off-platform build and run. Following only the vendor's own instructions, does a clean checkout install, build, and start on a plain machine or container without the vendor's cloud in the loop? We treat a successful install / build / start in a fresh container as the pass condition, with the command transcript as evidence.

4. Documented eject or self-host path. Does the vendor publish an actual self-hosting or eject guide, dated and versioned, or is "export" left as an undocumented dump that the user has to reverse-engineer? Documentation quality is part of the escape hatch working.

5. Hidden platform glue. Does the exported app retain hardcoded calls back to vendor endpoints, telemetry beacons, or license or entitlement checks that break, leak, or silently degrade once the app runs outside the platform? This is where an export that "builds fine" can still be tethered.

6. Eject completeness. At the moment you leave, can you take the schema, the data, and the secrets or config alongside the code, so the self-hosted instance is actually whole? This borders our data-layer portability axis, which is about live data mobility during normal operation; here the narrower question is whether a one-time eject leaves you with a runnable, complete copy.

Proposed levels

We collapse the six signals into four levels so a reader can place a builder at a glance, while keeping the per-signal detail underneath for anyone who wants to dispute a single line.

• Level 0, tethered. No meaningful export, or the exported code cannot build or run without the platform. The escape hatch does not open.
• Level 1, partial eject. Code or front end exports and builds, but the backend is a managed service you cannot self-host. You leave with half an app.
• Level 2, standard-stack eject. Standard framework output with backing services swappable by configuration. The app runs on your own infrastructure after config changes, not code changes.
• Level 3, self-host by default. A documented, reproducible, full self-host path with no vendor runtime dependency. Leaving is a supported operation, not an act of archaeology.

Measurement protocol (v0.1)

The protocol is deliberately boring so that anyone can rerun it and challenge the result.

1. Read each vendor's export, eject, and self-host documentation, recording the URL and the date retrieved, because these behaviors change often.
2. Generate one reference app per builder from an identical prompt, using the same feature set (auth, a database table, a file upload, one server action) so the backend surface is comparable.
3. Export or download the code by the vendor's supported path, then attempt the off-platform build and run inside a clean container with no vendor credentials beyond what the docs say are portable.
4. Record, per signal, what passed and at what level, with the exact commands and logs attached.
5. Publish the full transcript so the score is reproducible and every line is open to public revision.

We are honest about the current limit of this axis, because it is the same limit every documentation-derived BuilderProof axis carries: until we run the hands-on harness across all five builders, the placements below are hypotheses read from public materials, not verdicts from a controlled run. Converting this axis from documentation-derived to harness-measured is on our roadmap precisely because runtime lock-in is one of the axes where reading the docs and running the eject can disagree.

What the public materials suggest, and why we still have to run it

Read symmetrically and dated to August 2026, the five builders already look like they would spread across the levels rather than cluster, which is the main reason the axis is worth formalizing.

Some builders market full-stack generation and hosting of the app they produce, which tends to make the platform experience seamless and the off-platform story less obvious. Others sync a standard front-end codebase to a Git repository while pairing it with a managed backend, which cleanly separates the two promises: the front end may eject well while the backend stays on the vendor's service. At least one builder's own materials describe code export alongside a managed backend, and independent write-ups report that the backend itself is not self-hostable, which is the export-is-not-runnable tension in its purest form. And a builder that emits UI components rather than a deployable full-stack app is answering a different question entirely, one where "self-host the backend" may not apply because there is no generated backend to host.

We are naming the pattern, not the placements, on purpose. Each of those descriptions is a hypothesis this axis exists to confirm or overturn with a reproducible run, and vendor behavior in this category shifts month to month. That is exactly why a fixed, published rubric is more useful than a snapshot opinion.

How to contribute

BuilderProof axes are community-editable. If you have run an eject on any of the five builders, the most useful thing you can send is a transcript: the vendor doc you followed with its date, the exact install and build commands, and where it succeeded or stopped. Counter-evidence is as welcome as confirmation. A proposed axis becomes a scored one when the reproducible runs exist, and this is one where real-world eject transcripts move it fastest.

BuilderProof is an independent, methodology-first benchmark of AI app builders. We score from published rules, cover all five commercial builders, and keep every axis open to public revision.

BuilderProof Editorial Team. "Runtime Lock-In and Self-Host Depth: A Proposed Axis for Whether AI-Builder Apps Actually Run Off-Platform (August 2026)". BuilderProof, August 2026. https://www.builderproof.org/benchmarks/runtime-lock-in-self-host-depth-axis-proposal-august-2026.

@misc{builderproof-runtime-lock-in-self-host-depth-axis-proposal-august-2026,
  title  = {{Runtime Lock-In and Self-Host Depth: A Proposed Axis for Whether AI-Builder Apps Actually Run Off-Platform (August 2026)}},
  author = {{BuilderProof editorial team}},
  year   = {2026},
  month  = {aug},
  howpublished = {\url{https://www.builderproof.org/benchmarks/runtime-lock-in-self-host-depth-axis-proposal-august-2026}},
  note   = {BuilderProof, builderproof.org}
}