An AI app builder comparison needs an exit test

A founder can get a convincing product demo from Lovable, Bolt, Replit or v0 in an afternoon. That is no longer the hard part. The hard part is knowing whether the demo is becoming a company asset or a monthly dependency that gets more expensive and harder to change with every prompt.

My choice would depend less on which builder makes the prettiest first screen and more on the exit route. Lovable is the most approachable product builder for a non-technical founder, Bolt offers a particularly direct code escape, Replit covers the broadest path from idea through a running backend, and v0 is strongest when the intended destination is a conventional Next.js team. None removes the need for engineering judgment once the app handles money, permissions, private data or operational promises.

Choose by the asset you are buying

Ownership has four separate layers, and product comparisons routinely collapse them into one checkbox. You may own the legal rights to generated output, possess a copy of the source, control the repository where changes land, and still lack operational ownership because nobody can deploy or repair the app without the builder. A founder who asks only whether code can be exported has asked one quarter of the question.

Source possession means you can download or clone readable files. Repository control means the canonical history sits in an account your company administers. Runtime portability means the app can run on infrastructure that the builder does not control. Maintenance portability means a competent engineer can understand the stack, reproduce the environment, run tests and ship a fix without reconstructing hidden setup. The last two determine whether an export is useful.

• Lovable fits a founder shaping a web product. It exits through GitHub sync or a full ZIP, runs naturally on Lovable Cloud, Supabase or another web host, and strains when the app needs an existing repository imported.
• Bolt fits a founder who wants a browser build environment with an obvious file exit. It offers ZIP, StackBlitz and GitHub routes, while repository growth makes each AI turn consume more tokens and context.
• Replit fits a founder building frontend, backend and jobs together. Git and GitHub provide the source exit, and the main warning is that production spend and Agent spend become separate systems to manage.
• v0 fits a team committed to React and Next.js. GitHub can hold the source of truth, external deployment remains possible, and the ceiling appears when requirements move outside its preferred web stack.

That table is a routing map, not a winner board. If you need a mobile-native client, unusual infrastructure, strict regulated-data controls or a mature repository with a complicated build system, the shortlist changes before visual quality enters the discussion. If you need to validate a browser product with ten customers next week, the fast route may be worth some future migration work.

The contract test belongs beside the technical test. Confirm that the company account, not a contractor's personal login, controls the workspace, repository, deployment, domain, database and payment method. Read the current terms for output rights and third-party components. Generated code can include dependencies under their own licenses, and legal ownership does not guarantee that the implementation is original, secure or maintainable.

Lovable is the clearest founder-first product path

Lovable is the easiest of the four to recommend to a non-technical founder who wants to shape a web application rather than assemble isolated interface components. It combines conversational building, direct code access, a hosted backend option and a simple path into GitHub. Its official FAQ says the creator owns the projects and code, and its code editor can download the full project as a ZIP on paid plans. Those are meaningful exits, not a screenshot export.

The GitHub connection is stronger than a one-time backup. Lovable documents two-way synchronization on the default branch, with GitHub becoming the source of truth after connection. A developer can clone the repository, edit locally and push changes that return to Lovable. If the connection is later removed, the repository and its history remain in GitHub. That is enough to start a normal engineering handoff.

There is an awkward boundary: Lovable can create and sync a repository for a project, but its documentation says you cannot start by importing an arbitrary existing GitHub repository. That makes it better for a product born inside Lovable than for a founder trying to place an agent on top of a mature codebase. The connection also depends on the exact repository owner, location and name, so casually moving or renaming the repository can break synchronization. Company repository governance should start before the first serious build, not during due diligence.

The generated stack is portable but not abstract. Lovable says newer applications use TanStack Start with server-side rendering, while older projects use React and Vite; Tailwind remains part of the setup. Backend work may use Lovable Cloud, Supabase or external APIs. An exported frontend can be straightforward while authentication, database policies, storage, secrets and edge functions still require a planned migration. Ask a developer to identify every managed dependency before calling the project portable.

Lovable's current pricing uses credits whose consumption varies by task complexity and mode. Free workspaces receive daily build grants, paid plans add a shared credit balance, and cloud hosting plus AI features inside the finished app also draw from credits under the newer unified billing model. This makes the first experiment inexpensive, but it also means build activity and production activity can compete for a budget unless the founder tags them separately.

Choose Lovable when the founder needs to own product iteration personally, the target is a web app, and a developer can review the repository before launch. Do not choose it because the early screens look finished. Choose it because the workflow lets a founder discover the product and then hand a recognizable web stack to an engineer.

Bolt offers the most visible file exit

Bolt makes departure easy to understand: its project menu can download a ZIP, open the project in StackBlitz, or connect the work to GitHub. That simple visibility matters for a founder who fears being trapped. The downloaded application still needs Node.js, dependency installation, environment variables and a deployment target, but the files do not hide behind a proprietary visual format.

Bolt also has a useful route into existing public code. Its documentation describes opening a public GitHub repository by placing the Bolt path in front of the repository address, while its GitHub integration supports version-control workflows. That gives it a more natural relationship with code that already exists than a builder that only exports new projects. Private repositories, branch protections and organization permissions still need a real test with the exact plan and company account.

Its cost curve deserves more attention than the headline subscription. Bolt says most token usage comes from reading, understanding and synchronizing the project's file system. As the repository grows, an apparently small request can cost more because the agent must consume more context before making the edit. This is a structural cost, not a prompt-writing failure. Splitting a coherent application into artificial fragments may reduce context temporarily, but it raises integration risk and usually produces worse architecture.

The current free plan lists a monthly token allowance with a daily cap. The entry Pro plan starts at $25 per month with 10 million monthly tokens, hosting and custom-domain support, while higher token tiers raise the subscription. Paid subscription tokens roll over for one additional month while the subscription remains active. Those numbers can change, so use them to understand the billing shape, then copy the live pricing into the project's budget on the day you decide.

Bolt hosting makes publication quick and includes request and bandwidth allowances. That convenience should not blur two separate costs: generation tokens pay for changing the application, while hosting capacity pays for running it. A quiet application with a large repository may consume little hosting and many build tokens. A simple landing page with heavy traffic can do the reverse.

Bolt fits a founder who wants rapid browser-based construction, direct access to JavaScript files and the option to move into a conventional developer workflow. Its ceiling appears when the agent repeatedly rereads a growing codebase, backend behavior becomes hard to reason about, or changes require careful cross-file migrations. At that point, use Bolt as an accelerator inside repository discipline, not as the discipline itself.

Replit reaches furthest into the runtime

Replit covers more of the application lifecycle inside one product than the other three. Agent can plan, create frontend and backend code, work with databases, run the project, produce checkpoints and publish through several deployment types. For a founder building a marketplace, internal tool or API-backed application, that breadth can remove days of account setup. It also joins more concerns under one bill and one operational surface.

Replit checkpoints capture more than a Git commit. Its documentation says they include project files, Agent conversation context and connected database state, and they can be rolled back from the workspace. Git remains available alongside checkpoints, including command-line access and GitHub integration. This distinction matters: a checkpoint is a convenient workspace recovery tool, while Git is the portable history that survives a platform move and fits code review. Keep both, but never treat one as a substitute for the other.

Agent billing is effort based. Replit explicitly says all Agent interactions are billable, including guidance or planning that makes no code change, although smaller requests cost less. Core currently costs $25 month to month or $20 per month when billed annually and includes $25 in monthly credits; Pro adds a larger monthly credit pool and more concurrent agents. The credit pool also pays for cloud services, so a founder should not read the subscription price as a fixed build budget.

Production pricing is its own curve. Replit offers static, autoscale, reserved VM and scheduled deployments. Autoscale charges for requests and compute while work runs, reserved machines trade utilization risk for predictable capacity, and scheduled deployments suit recurring jobs. Databases, storage, outbound transfer and AI integrations may add usage. This is more transparent than pretending runtime is free, but a non-technical founder needs a monthly budget alert and a named owner for it.

Replit has the highest functional ceiling here for a founder who needs working backend behavior without assembling services manually. It also creates the greatest temptation to let one platform become editor, agent, database console, runtime, incident history and billing system. Exporting source alone will not recreate database state, deployment settings, secrets or scheduled jobs. A credible exit rehearsal must document each of those pieces.

Choose Replit when breadth and speed to a working full-stack system matter more than having the lightest possible platform footprint. Before real users arrive, put the code in a company-controlled GitHub organization, document the deployment variables, enable spending controls and prove that another engineer can run the app from a clean checkout.

v0 fits a deliberate Next.js destination

v0 is the strongest choice when the destination is already Next.js, React, TypeScript, Tailwind CSS and shadcn/ui rather than an unspecified application. Its advantage is not that every generated screen is better. Its advantage is that the generated work lands in a stack many web teams already recognize and can absorb into normal pull requests.

The current GitHub workflow makes the repository the source of truth. v0 documents automatic branches and commits, avoids pushing directly to the protected main branch, and lets a team merge through a pull request. It can also import an existing GitHub repository or uploaded ZIP. This is the cleanest collaboration model in the group for a company that already has engineers and wants a product person to propose working interface changes without bypassing review.

Vercel is the natural production home and supplies the fullest preview, environment and deployment experience, but the official FAQ says code can still be exported and deployed elsewhere. That is real portability with a qualification: a Next.js application may use platform-specific deployment behavior, image handling, server functions, analytics or storage integrations. The source can leave while some operating assumptions stay behind. A developer should run the production build against the proposed alternative host before anyone claims an easy migration.

v0 currently offers a free tier with a small monthly credit balance, while Team is $30 per user each month and Business is $100 per user. Monthly credits pay for generations, unused credits have a limited rollover window, and teams can buy more. The per-user model is predictable for a small product group, but costs rise with seats and iteration. It is less attractive when many occasional collaborators need access or when the main work is backend orchestration rather than interface and web application changes.

A non-technical founder can use v0 successfully, but the product assumes more architectural intent than Lovable. Someone must decide repository structure, environment handling, data boundaries and deployment conventions. If those decisions already exist, v0 respects them. If they do not, the founder may receive technically familiar files without a coherent system around them.

Choose v0 for an app that is meant to become a conventional Next.js codebase under team review. Avoid it when the stack requirement is open, mobile-native work dominates, or the founder expects one agent to own every production concern.

The cost curve begins after the first demo

The subscription is usually the smallest cost once an AI-built app becomes a business. The budget has at least five lines: generation, human review, managed services, migration work and failure recovery. Vendors expose different units, so comparing $20 with $25 says almost nothing about the cost of reaching a stable release.

Use one feature as the measuring unit. Pick something representative, such as inviting a teammate with role-based access, and take it from request through production. Record the prompts or Agent tasks, credits or tokens, elapsed founder time, developer review time, bugs found after deployment and any new paid service. Repeat the same measurement after the repository has doubled in size. That second run reveals the slope.

• For AI construction, record credits, tokens or effort charges by feature. Treat rising cost for the same scope as a warning.
• For human correction, record founder and engineer hours spent diagnosing generated work. Compare review time with the time needed to write the change directly.
• For runtime, record hosting, database, storage, transfer and model calls. Every charge should map to a feature, environment or customer group.
• For portability, record the hours needed to reproduce builds and deployments elsewhere. A release that only works from the original workspace has failed the test.
• For failure recovery, record rollbacks, data repair and support time. Restoring code is insufficient when data or configuration remains damaged.

Do not optimize token counts before measuring correction time. A cheap generation that creates a permissions bug is expensive. Do not compare only successful prompts either. The discarded attempts and plan conversations are part of product development, and some builders bill them. Use the invoices and usage dashboards, not a founder's memory.

Keep a separate budget for the handoff itself. A repository may look ordinary while the first outside engineer spends hours locating generated database policies, tracing environment variables and learning which deployment action changes production state. Record that work against the builder decision, even if it happens after cancellation. Also price the founder's delay: if a feature waits three days because nobody trusts the generated migration, the subscription invoice understates the cost. This is why a slightly more expensive builder can be the cheaper choice when it creates conventional files, clear history and a release process another person can follow. The comparison must include the time needed to explain the application to its next owner.

Model one bad month as well as one normal month. Include a failed deployment, an urgent permissions fix, extra agent attempts, database restoration and the engineer who checks the result. A builder that looks cheap only when every generation succeeds has an unrealistic budget. Then decide who may increase spending limits and what evidence they must see first. Keep production usage alerts separate from build-credit alerts so a burst of customer traffic does not look like an unproductive agent session. Review both at the feature level each week until the team understands the pattern. Once usage stabilizes, a monthly review is enough, but keep alerts active because a loop in application code can change runtime spend without any new prompt.

The best cost control is narrower scope. Keep the first release to one user type, one paid outcome and the few workflows needed to deliver it. This is product discipline, not a concession to AI limits. A smaller domain also gives the agent less irrelevant context, gives the reviewer fewer permission paths to inspect and makes an exit rehearsal possible in hours rather than weeks.

A five-part exit test exposes lock-in

An export button proves little until the application runs outside its original workspace. Perform the exit test before customer data becomes difficult to move, then repeat it after every major infrastructure change. A founder can coordinate the test, but an engineer should verify the result.

1. Put the repository in a company-controlled organization. Clone it into a clean directory using an account that did not create the project. Confirm that source history, assets, migrations and lockfiles are present.
2. Rebuild without the builder's preview. Install the documented runtime, restore dependencies from the lockfile and produce a production build. Record every undocumented manual action.
3. Replace the managed environment. Load secrets from a fresh environment, create an empty database, run migrations and seed only non-sensitive test data. Do not copy a live database to make the test pass.
4. Deploy to a second target. Use a temporary host that the builder does not control, exercise authentication, file uploads, email or payment webhooks, background work and error reporting. Test the boring paths where migrations fail.
5. Make and release one change. Ask an engineer who did not build the app to fix a small bug through a branch and pull request, deploy it, then roll it back. Measure missing documentation rather than coaching them through it.

The output is a short exit record: repository owner, stack and runtime versions, environment-variable names, database export and restore procedure, deployment command, domain controls, recurring jobs, external services, last successful rehearsal and open blockers. Do not put secret values in that record. Store the record with the repository so it leaves with the code.

A failed test does not always mean replacing the builder. It tells you what dependency you are accepting. A prototype may reasonably depend on a managed database for six weeks. A payroll product with paying customers should not depend on a founder remembering which hidden switch makes production deploy. Price the repair and set a deadline.

Match the builder to the next risk

Choose the product that removes the next business risk, not the one that wins the broadest feature checklist. A pre-revenue founder usually needs evidence that users care. A funded company with an existing repository needs controlled contribution. A live application needs predictable operations and repair. Those stages can justify different builders.

Pick Lovable when a non-technical founder must drive web-product discovery and wants a clear handoff into GitHub. Pick Bolt when direct file access, a browser development environment and flexible JavaScript experimentation matter, especially if you want a visible ZIP escape from day one. Pick Replit when the immediate blocker is getting frontend, backend, jobs and deployment working together. Pick v0 when the destination stack and GitHub review process are already decided around Next.js.

Do not make a four-week bake-off. Give each serious candidate the same two-day assignment: implement one permissioned workflow, connect a real but disposable external service, export it, and have someone else run it. Score the resulting repository and operating notes, not the presentation. The tool that needs the fewest explanations after export is usually safer than the tool with the most impressive first prompt.

There are clear rejection conditions. Reject any setup that cannot place code in a company account, cannot reproduce a production build, hides data export, gives every user excessive database rights, or has no spend limit for usage-based services. Reject a generated dependency you cannot license or patch. Pause launch when nobody can explain the authentication and authorization paths in plain language.

A founder should still expect to hire technical judgment. The question is when and for what. Paying an engineer for a focused architecture and security review before launch is sensible. Paying one to reconstruct months of undocumented prompt changes during an outage is avoidable.

The ceiling arrives as coordination work

AI builders rarely fail because they cannot render one more settings page. They hit a ceiling when a change crosses permissions, data migrations, background jobs, external APIs, tests and deployment at once. The agent can edit all those files, but someone must decide the safe order, define invariants and know which state cannot be rolled back. That work is engineering leadership.

Watch for practical signals: fixes cause regressions in distant features, the agent repeatedly reverses earlier architecture, nobody reviews database policies, preview and production behave differently, or a simple request consumes several rounds of repair. Another signal is organizational: the founder avoids an important change because the prompt feels dangerous. That means the product already has complexity without ownership.

The response is not an immediate rewrite. Freeze new surface area, put the repository and production accounts under company control, add tests around revenue and permissions, document the runtime, and assign one engineer to own releases. Continue using the builder where it remains fast, but route consequential changes through branches, review and a rollback plan.

For founders who cannot tell whether they have reached that point, the Team & AI Audit on oleg.is examines the team, toolchain and cost base over five business days, with a fixed $5,000 price and a stated guarantee of at least $50,000 in annual identified savings or the audit is free. That is most useful before hiring a conventional team around an application whose architecture nobody has assessed.

Run the exit test while the app is still small. If it passes, keep shipping with the builder that fits your next risk. If it fails, you have found the exact migration work before a customer, investor or outage finds it for you.