Bolt.new vs Lovable vs Replit, What Happens After the Prototype
All three tools stop short of the finish line
Bolt.new, Lovable, and Replit are the three most commonly used AI prototype builders in 2026. Each has a large user base, a strong track record for rapid prototype delivery, and a specific and well-documented set of failure modes at the point where the prototype needs to become a production application.
The failure modes are different for each platform. Understanding which platform you used, and which failure patterns to expect, is the first step toward a systematic production review.
This comparison covers each platform's architecture, its approach to production deployment, and the specific engineering work required to bridge the gap between the platform's output and a stable production application.
Bolt.new
How it works
Bolt offers built-in hosting, so publishing does not require an export to GitHub or a third-party host. The portability checks below apply when you choose to move a project to another hosting environment. Check the target runtime, database, secrets and build configuration before switching traffic.
What the prototype output looks like
Bolt provides its own hosting and Bolt Database, with Supabase also available. If the project is exported to GitHub and moved to another host, review runtime configuration, database access, build commands and environment variables for that target. A working preview does not establish that the exported deployment is configured correctly.
The production gap
Bolt.new's primary production gap is environment portability. The WebContainer environment is not a standard Node.js runtime. Environment variables, package resolutions, and filesystem behaviour in WebContainer have characteristics that do not map directly to Vercel, Netlify, or any real hosting provider. When you export the project and deploy it, the differences surface as build failures, runtime errors, and missing configuration.
The most common failure modes, in approximate frequency order:
- Environment variables not present in the hosting platform (they existed in WebContainer's runtime, not in exportable form)
- Package incompatibilities between WebContainer and standard Node.js
- Build configuration mismatches for the target hosting platform
- Supabase RLS not configured for production data access requirements
- Auth redirect URIs pointing at WebContainer preview rather than production domain
What a production review covers for Bolt.new
The engineering work to take a Bolt.new project to production is primarily configuration and environment work rather than code rewriting. The codebase is often structurally sound; the gaps are in the connection between the code and the production infrastructure. Exceptions include projects that have been through many rounds of iterative AI fixes, where the code quality may have degraded.
Lovable
How it works
Lovable's own hosting and built-in Cloud backend are the default route. Its documentation, read on 14 October 2026, says new apps created from 13 May 2026 use TanStack Start; older apps use React with Vite. Both can be moved to other hosting, but TanStack Start needs a server runtime as well as static file hosting.
What the prototype output looks like
Moving a Lovable project to Vercel is a separate deployment through the project's code repository. Configure the target host and its environment variables, and review any backend services and connections that remain with Lovable or move to Supabase or another provider. Do not assume a successful build also proves that data access is secure.
The production gap
Lovable's production gap is primarily security and configuration rather than portability. The application will deploy to Vercel. What it will not do, without human review, is deploy securely.
The most common failure modes, in approximate frequency order:
- Supabase RLS misconfiguration (described in CVE-2025-48757, which the supplier disputes)
- Auth redirect URLs configured for Lovable's preview domain rather than the production domain
- Stripe in test mode, with no webhook verification, deployed to production
- API keys in NEXT_PUBLIC_ environment variables (accessible to the browser)
- Vercel environment variables not configured after initial deployment (configure the target host with the required environment variables)
What a production review covers for Lovable
Lovable applications require a security-first production review. The deployment infrastructure often works; the security posture is the problem. Supabase RLS policy review is mandatory for any Lovable application before real users interact with it. Auth URL configuration, Stripe live mode setup, and environment variable audit follow. For applications in regulated sectors, the UK GDPR and sector-specific review is particularly important because Lovable's ease of use has brought regulated-sector founders, solicitors, IFAs, GPs, into vibe coding without a clear view of their compliance obligations.
Replit
How it works
Replit provides a cloud-based development environment with a built-in AI assistant (Replit AI) and, more recently, Replit Agent, an autonomous AI that can build, iterate, and deploy applications with minimal human intervention. Replit's environment is a complete Linux-based development environment running in a browser. Deployments run on Replit's own infrastructure, there is no need to configure an external hosting provider unless you want to move off the platform.
What the prototype output looks like
Replit applications are more varied than Bolt.new or Lovable outputs because the environment is more flexible. Applications built with Replit Agent can use any framework and any backend; the agent makes technology choices as part of its implementation work. This flexibility produces higher architectural variance, some Replit Agent applications are well-structured, others are not, compared to the more constrained outputs of Bolt.new and Lovable.
The production gap
Replit's production gap is primarily the difference between Dev mode (the interactive development environment) and Deployed mode (Replit's containerised production runtime). These are different execution contexts with different resource constraints, different filesystem access, and different environment variable resolution. Applications that work correctly in Dev mode can fail silently after deployment because of differences the developer is not aware of.
Replit's current documentation describes separate development and production databases. This reduces the risk of development work changing the production database it provisions. Review any external production credentials, tools or infrastructure exposed to an agent separately, and inspect changes before release.
The most common failure modes, in approximate frequency order:
- Production credentials differing from the workspace values, or secrets changed after the last publish
- Workspace versus published-app runtime differences causing silent failures
- Replit Agent changes that are outside the intended scope of the session
- Package version conflicts masked by the Dev environment
- Custom domain and auth URL configuration not updated for production
What a production review covers for Replit
Replit applications require both a deployment configuration review (secrets migration, Dev/Deployed mode differences) and, if Replit Agent has been used in the session history, an agent change audit. The agent audit is an examination of the Git history to identify changes made autonomously during agent sessions, verifying that those changes are intentional and that they have not introduced security or stability issues.
The common thread
Despite their different architectures and different failure modes, all three platforms share the same underlying dynamic: they are optimised for the prototype, not the production environment. The prototype is what they demonstrate in marketing material, what users evaluate in trials, and what founders show to early customers. The production environment, with real user data, real payment flows, real compliance obligations, and real security exposure, is a different context entirely, and none of the three platforms has automated the transition to it.
The engineering work required to close that gap is bounded and knowable, but it requires a senior engineer who understands both the platform's specific failure modes and the production environment's requirements. That is the purpose of the AI App Diagnostic Audit, an independent review of your specific codebase, with a written recommendation and a scoped quote for whatever remediation is needed.
Frequently asked questions
- Which of the three platforms produces the most production-ready output?
- Bolt.new typically produces the most structurally sound code, particularly for smaller applications. Lovable deploys most easily but has the most documented security incidents. Replit is the most flexible but adds risk if Replit Agent has been used with access to production infrastructure. None of the three produces a production-ready application without a human engineering review.
- Can I move my Lovable app to Vercel without a security review?
- Review the code repository, target runtime, backend access policies, authentication URLs and environment variables before moving a Lovable app to Vercel. Lovable's own hosting is separate. A successful deployment is not evidence that access control, payments or data protection have been checked.
- My Bolt.new app builds on my machine but fails on Vercel. Is that a Vercel problem or a code problem?
- Almost always a code or configuration problem, not a Vercel problem. The most common cause is environment variables present in Bolt.new's WebContainer that were not added to Vercel's environment variable settings. The second most common cause is a build configuration difference between WebContainer and Vercel's Node.js runtime.
- Is Replit Agent safe to use on a production application?
- Replit Agent is appropriate for development tasks on development environments with development data. Using it on a production environment, with write access to a production database, production secrets, or production infrastructure, carries documented risk. If you have used Replit Agent on a project with production infrastructure access, a review of the agent's change history is a standard part of the production readiness process.
Get new briefings by email
The AI Consultancy newsletter delivers briefings and analysis for UK businesses. We use your address only to send it, and you can unsubscribe at any time.