Which AI coding platform is best for an app that has to run in production?

Almost every comparison of these four measures the wrong thing. They rank the tools on how quickly a good-looking app appears, which is a genuine difference and also completely irrelevant three months later, when you have customers and the question has changed from "can I build it" to "what happens when it goes wrong".

This is that second comparison. It is less fun and considerably more useful.

First: these are not four of the same thing

Lovable, Bolt and Replit build your app and then run it. They give you hosting, a database, authentication and a deployed URL. That is enormous convenience and it means the platform sits inside your production stack permanently.

Cursor does not do any of that. It is an editor that runs on your machine and helps you write code, and then you deploy that code wherever you like. Nothing of Cursor is in production, because there is no Cursor in production.

That distinction reorganises the whole comparison. Three of these are infrastructure decisions. One is a tooling decision. Comparing them on a single axis produces nonsense, which is why most comparisons of them read strangely.

The question that actually decides this

For the three hosting platforms, everything comes down to one thing: what stops one customer from reading another customer's data.

On all three, the answer is essentially the same technology. They all use Postgres with row-level policies — rules that live in the database and decide, per row, who may read or write it. Lovable's Cloud is Supabase underneath. Bolt's Cloud is described as running on trusted platforms including Netlify and Supabase. Replit provisions its own managed database inside single-tenant infrastructure.

So the primitive is shared. What differs is everything around it: whether the platform tells you your policies are wrong, whether you can read them, whether you can change them directly, and whether anyone has ever stated clearly whose job it is to check.

That last one turns out to be the sharpest difference between the four.

Lovable

Lovable has been examined more thoroughly in public than the other three combined, and it has two published incidents behind it.

The first was a vulnerability disclosed in May 2025, rated 9.3 out of 10, concerning access control on generated projects — the researcher reported finding hundreds of exposed endpoints across a large number of projects. Lovable has disputed aspects of that finding, which is worth stating alongside it. The second was a separate exposure running for roughly two and a half months in early 2026, reachable with a handful of API calls from a free account, where the earliest reports through the disclosure programme were not acted on and the problem was fixed within hours once it became public.

Neither of those is a good look, and I am not going to pretend otherwise. But what happened next is the interesting part.

Through the first half of 2026, Lovable shipped a steady run of security capability: third-party vulnerability scanning, scanning specifically for personal information exposure, configurable scan profiles with automatic fixes, workspace-level insight into which projects have problems, and automatic revocation of leaked API keys. Some of it is gated to higher tiers, which is a fair criticism. But taken together it is the most detailed security tooling of the three hosting platforms, and it is explicitly aware of the row-policy problem rather than being generic code scanning.

Lovable's own documentation is also direct about where responsibility sits: it sets up basic policies automatically, tells you to review them, and states plainly that meeting the security requirements appropriate to your use case is your job — particularly with sensitive data. Its exit documentation is similarly blunt that leaving means taking on infrastructure, databases, authentication and security review yourself.

I have written a full post on what that boundary actually means in a Lovable app, because it is the single most consequential thing to understand about the platform.

Bolt

Bolt's story is the hardest to write honestly, because the notable thing about it is an absence.

There is no publicly disclosed vulnerability of comparable severity. No CVE. No named research disclosure. No postmortem. When a security firm scanned thousands of AI-built applications in late 2025 and found a large number of vulnerabilities and exposed secrets, the sample was heavily weighted toward Lovable and did not break Bolt out separately. When another firm named platforms in a 2026 report on leaking apps, Bolt was not among them.

The temptation is to read that as a clean bill of health. It is not, and I want to be precise about why: an absence of public incidents measures how much scrutiny a platform has received, not how sound it is. Nobody has published a serious look at Bolt. That is a fact about the research community's attention, not about Bolt's code.

Two other gaps are worth naming. Bolt's own security documentation never mentions row-level security by name, despite running on the same primitive as Lovable — so the mechanism that decides whether your customers' data is separated is not something the platform's own materials point you at. And I could not find any published statement of where Bolt's responsibility ends and yours begins; the applicable terms of service are the parent company's, dated well before Bolt existed, and never mention the product.

On capability, Bolt has moved: security review on publish arrived in late 2025, leaked-password protection in mid-2026, and a full project audit feature at the end of July 2026 — the last of those on paid plans only. Its status page shows the ordinary pattern of short outages, none security-related.

And in May 2026 Bolt announced a partnership with Microsoft. A partnership, not an acquisition, which is worth stating because it has been reported as both.

Replit

Replit is the only one of the four that publishes a shared responsibility model — a page that says explicitly which controls the platform provides and which decisions are yours. That sounds like a small documentation detail. It is the clearest signal in this comparison that somebody has thought about production seriously, because the failure mode across this whole category is people not knowing there was a boundary at all.

Structurally it is also the most conventional: single-tenant projects on Google Cloud, four distinct deployment types depending on whether you want autoscaling, a static site, a permanently-running machine or a scheduled job, and a SOC 2 Type II report completed in 2025 with no exceptions. On security tooling it has a code scanner in the editor, a Security Center that has been through a substantial second version in 2026 including bulk-unpublishing exposed apps and agent-assisted fixing, a package firewall, and automatic protection features.

It also has the most alarming single incident in the category. In July 2025 Replit's agent deleted a user's production database during an explicit code freeze, then generated fabricated data and initially reported that a rollback was impossible when it was not. The user was a well-known software founder who documented it publicly. Replit's CEO called it unacceptable and said it should never be possible, and the company subsequently rolled out automatic separation between development and production databases.

That is the correct response, and the outcome — every user now gets a protection that did not exist before — is better than the counterfactual where it never happened publicly. But it remains the clearest illustration available of what an agent with production access can do, and it is why I am unenthusiastic about any workflow where the same agent that writes your code can also reach live customer data.

One structural note that matters more than it sounds: Replit's current managed database is reachable only from inside your own app and is never publicly exposed. That is a defensible security choice and it also means there is no documented path to connect an external tool — including a backup tool. I go into what that implies in what you actually own when you export.

Cursor

Cursor is in a different position entirely. It hosts nothing, so nothing about Cursor can leak your customers' data. What it can do is compromise the machine where your code lives.

It has the most serious published vulnerability record of the four. Two disclosed in mid-2025 — one rated 9.8 out of 10, allowing a malicious repository to trigger code execution, and one rated 8.8 involving trusted configuration being altered after approval. A third pair, also rated 9.8, was reported in February 2026, initially rejected by the vendor, assigned identifiers in June and patched in Cursor 3.0.

Read those carefully and the pattern is consistent: every one threatens the developer, through untrusted content arriving in the editor's context. That is a real risk with a real mitigation — be careful what repositories and external tool connections you open — but it is not the same risk as a deployed app exposing customer records.

Two other things belong in an honest picture. Cursor's terms include an emphatic clause placing sole responsibility for reviewing and testing generated code on the user, which is at least unambiguous. And while its terms assign the rights in suggestions to you and commit to not training on your code without agreement, your requests do pass through Cursor's backend, files are temporarily cached, and your codebase is chunked and embedded to make search work. That is a privacy consideration rather than an ownership one, and it may or may not matter depending on what your code is.

The inversion at the centre of this

Put the four side by side and something odd appears.

The platform with the worst public incident record now ships the most detailed, most row-policy-aware security scanning. The platform with a catastrophic public failure now ships automatic production separation that its competitors do not. The platform with no public incidents has the thinnest published security documentation and no statement of responsibility at all.

The causation runs in the direction nobody wants to hear: being publicly caught is the strongest driver of investment in not being caught again. Which means an incident history is a genuinely bad way to rank these products, and probably the opposite of what your instinct suggests.

The corollary is uncomfortable but worth saying plainly. If you are choosing on the basis that one of these has never had a problem, you are choosing on the basis that nobody has looked.

The corporate weather

All four are in motion. Lovable raised a very large round in 2025 at a multi-billion valuation and has been reported in talks at roughly double that since. Replit raised several hundred million at a similar scale. Bolt's parent announced its Microsoft partnership in mid-2026. And Cursor's parent company was announced in June 2026 as being acquired for tens of billions in stock, with the deal expected to close later in the year.

None of this affects your app on Monday. What it affects is roadmap predictability over a two-year horizon, and the honest position is that nobody — including the companies — can tell you what these products look like after that much capital and that much ownership change.

Which is not a reason to avoid any of them. It is a reason to make sure that the two things you would need in order to leave — your code in a repository you own, and a database you can actually connect to — are in place from the beginning rather than assembled in a hurry.

So which one

If you are testing whether an idea is worth building, take whichever of the three hosting platforms feels best to use. The difference in outcome is negligible and speed genuinely matters at that stage.

If you know this will take payments and hold customer data, the platform choice is less important than two decisions that cut across all of them: bring your own database from day one, and keep your code synced to a repository under your own account from day one. Both are available on every platform here and both take an afternoon at the start and a fortnight later.

If you have an existing app and are wondering whether to move it, the honest answer is that moving platforms almost never fixes the things people want it to fix. The problems I see are the same regardless of which tool produced the app, because they come from the shape of AI-assisted building rather than from any vendor. Switching relocates them.

And if you or someone helping you writes code directly, Cursor is not really competing with the other three — it is the thing you use after you have outgrown the phase where the platform builds everything for you.

Where this leaves you

The four platforms differ meaningfully in what they show you, what they take responsibility for, and what you can take with you. They do not differ much in whether the app they produce is ready for real users, because none of them claim to do that part and none of them do.

If you want to know where your own app stands, that is what I do: a Production-Ready Audit on whatever it was built with — the access boundary tested from a second account, the failure paths walked, plan limits checked against your real usage, ownership and export position written down, and a prioritised fix list with honest costs. From $499, back in five to seven days.

If you would rather start with a question, tell me which platform you are on and whether other people's data is in your database, and I will tell you which two things I would check first. No charge.

The full inventory of what tends to be missing is in the ten problems every AI-built app has in production, moving off a managed backend is covered in Lovable Cloud to your own Supabase, and the repair work itself is described on the AI SaaS rescue page.