Bolt.new alternatives: choose a path to ship a production app

A prototype that works inside a builder is not yet an app your team can keep shipping. If you are looking for Bolt.new alternatives because you need an inspectable repository, a deployment path you control, or a handoff to your own coding agents, compare the exit path before generated screens.

This shortlist uses four criteria: repository access, work outside the builder, documented deployment path, and web or mobile fit. Pricing and feature facts below were checked October 8, 2026.

If your actual question is whether Bolt Cloud or a repo-first kit fits your project, see our separate Bolt comparison. This page answers a different question: which kind of starting point fits the way you want to own and operate the app?

Start with an exit test, not a feature checklistCopy Anchor Link

Before choosing a builder, write down what “own the app” has to mean for your team. A GitHub connection can be useful without giving you an independent production path. A download can give you the files without preserving the original hosted database, secrets, domain, or build environment. Treat each as a separate check.

Use this test against the app you intend to ship:

1. Can you create or receive a repository in the GitHub organization that should own the work?
2. Can a developer clone it, install from its lockfile, and run the documented build without opening the builder?
3. Can you make a small change locally, review it in Git, and deploy it through the path you intend to operate?
4. Do you know where production data, environment variables, custom domains, and runtime costs live?
5. If the app needs iOS or Android, does the workflow produce the native deliverable you need, or only a responsive web page?

If you cannot answer those questions from a vendor’s documentation, run a small proof before moving a customer-facing app. Do not infer an exit path from a “GitHub integration” badge alone.

Lovable: keep the visual builder and add a Git handoffCopy Anchor Link

Lovable is a fit when you want to keep building in its chat interface but need a repository for local coding, review, or another deployment target. Its current GitHub docs describe export and two-way sync, including working locally in an IDE and deploying outside Lovable. The connection syncs one active branch at a time, which means your team should verify the active branch before editing locally or asking an agent to work on another branch.

There is an important boundary: Lovable’s current documentation says GitHub sync exports from Lovable and does not import an existing GitHub repository into a Lovable project. If you already have a repository and want to keep that repository as the source of truth inside the builder, confirm the current import limitation before investing in a migration. The documentation lists direct codebase downloads through Project settings → Git or the Code editor, and notes that this download is available on paid plans.

Pricing is usage-aware rather than a single flat build cost. Lovable’s pricing page describes credits for building, hosting, and AI features; the amount consumed depends on the action and plan. Estimate builder work and hosted-app usage, and set a workspace limit before inviting a team to share credits.

Choose Lovable if the visual chat loop is valuable and a managed GitHub handoff is enough. Choose another path if importing an existing repository into the builder is a must-have or if the active-branch model does not fit your release process.

Replit: use a browser workspace with Git and hosted deploymentCopy Anchor Link

Replit is worth evaluating when your team wants the editor, AI-assisted changes, version control, and deployment close together in one browser workspace. Its documentation says you can import a GitHub repository, modify and push code between Replit and GitHub, and use branches through its Git interface. The product introduction describes creating and deploying apps from the browser, while the pricing page presents plans and usage controls.

That makes Replit a different kind of alternative: it reduces setup by keeping more of the development loop in one hosted workspace. It is not the same as choosing an independent deployment target. Before moving a live app, test the precise exit route you need: clone or push the repository, identify which settings and secrets are outside Git, and confirm where the production deployment will run. If your team is comfortable operating the app in Replit, its integrated editor-to-deployment path may be the point. If infrastructure control is the requirement, treat that as a separate acceptance test rather than assuming Git support settles it.

For a production rollout, compare the plan and usage details for your expected deployment shape. Replit’s pricing page includes plan tiers and usage-related billing questions; the exact monthly amount depends on the current plan and usage. Record the pricing page date in your decision so a later plan change does not silently alter the cost assumptions.

Choose Replit when a managed browser workspace is the workflow you want. Choose a repo-first option if you want to start with a codebase that is already organized for a separate local development and deployment process.

v0: generate web apps inside a GitHub and Vercel workflowCopy Anchor Link

v0 fits teams that want to generate web interfaces and applications and already expect to use Vercel. Its official documentation describes connecting a v0 project to a Vercel project and deploying from the v0 interface. The current pricing page also lists GitHub sync and deployment to Vercel on the free tier, with paid plans and additional usage options.

This path is strongest when the deployment destination is part of the decision. A repository helps preserve and review the code, while Vercel provides the documented deployment workflow. Confirm that the resulting application’s runtime, data services, environment variables, and operating costs fit your release plan before committing to the workflow. If you need native mobile binaries, verify that requirement separately; the published v0 path is centered on web generation and Vercel deployment.

Choose v0 if you want a web-first builder that plugs into a Vercel-centered workflow. If your organization expects to operate on another platform, test a clean checkout and deployment before treating the GitHub connection as proof of portability.

OTF Kit: start with a repository instead of a prompt-to-app projectCopy Anchor Link

OTF Kit is a different option for teams that already know they want a codebase their own developers or agents will continue to extend. It is a set of app and site starting points, not a chat builder that generates a new project from a prompt. The public product pages describe editable source delivered through a repository, coding-agent configuration stored with the code, and deployment scripts for the offered products.

The full-stack kit pages list a one-time $99 individual kit price; the product catalog also offers a $149 bundle. Check the current product and license page before checkout, because what is included and the permitted developer seats matter as much as the sticker price. For mobile work, inspect the specific kit: the Fitness Kit page describes a mobile app targeting iOS, Android, and web. Do not assume that every kit has the same platform support or backend.

This is the repo-first choice when you prefer to begin with source and a pre-wired application structure, then use Cursor, Claude Code, or another supported coding agent to make product changes. It is not the right fit if you want the builder to generate a bespoke app from a conversational prompt or you need a product feature that the selected kit does not contain. Click through the live demo and read the product-specific docs before buying.

Pick by the constraint you cannot compromiseCopy Anchor Link

• You want a visual chat builder and a local Git handoff: evaluate Lovable, then test its active-branch sync and deployment path.
• You want a hosted development workspace with deployment nearby: evaluate Replit and decide whether its managed runtime fits your operating model.
• You already ship web apps on Vercel: evaluate v0, then verify the code and service boundaries in a clean repository.
• You want to start with an owned repository and a known app structure: inspect the specific OTF Kit demo, source-access path, license, and deploy instructions.
• You need native mobile: verify the actual iOS/Android workflow and build output before selecting any web-first option.

For each finalist, clone or export a small project, install dependencies, run its documented check, change one feature, review the diff, and deploy it. Record the result; this tests whether your team can keep shipping better than a feature grid.

SourcesCopy Anchor Link

• Bolt pricing — plan and token information checked October 8, 2026.
• Bolt introduction and supported technologies — JavaScript apps, GitHub, and mobile-app support checked October 8, 2026.
• Lovable pricing and GitHub sync documentation — credit model, download, two-way sync, active branch, and import limitation checked October 8, 2026.
• Replit pricing, version control, and product introduction — plan, GitHub, and hosted workspace capabilities checked October 8, 2026.
• v0 pricing and v0 documentation — GitHub sync, Vercel deployment, and plan details checked October 8, 2026.
• OTF Kit and Fitness Kit — repository delivery, product pricing, agent setup, and mobile details checked October 8, 2026.