My Lovable or Bolt app keeps breaking. Rewrite it or make it production-ready?

If people already use and pay for your app, don’t rewrite it. Keep the screens and flows your customers know, and fix what sits underneath in order of risk: who can see which data, backups, payments, then how changes get deployed. Rewrite only when there is no real backend under the screens or when the product itself is about to change so much that the current screens won’t survive.

“Keeps breaking” is usually a symptom of missing foundations: no tests, no safe way to deploy, rules about data written only in the browser. Those problems are fixable without throwing away the part that customers have already validated.

Why does an AI-built app keep breaking?

Tools like Lovable, Bolt, Replit and Cursor are very good at producing screens that work in a demo. They are much weaker at the invisible parts of a product: permissions, data safety, retries and repeatable releases. Andrej Karpathy, who coined the term “vibe coding”, described it as “not too bad for throwaway weekend projects” (Karpathy on X, 2025). Your app stopped being a weekend project the day the first customer paid.

Three things make the breakage feel random:

• No tests. A test is a small program that checks a feature still works after every change. Without them, each new prompt can quietly break something that worked yesterday, and you find out from a customer.
• No staging. Changes go straight to the live app, so every experiment is an experiment on paying users.
• Rules in the wrong place. If “users only see their own records” is enforced by hiding a button in the browser, it isn’t enforced at all. The rule has to live on the server or in the database.

None of this means the code is worthless. It means the code is missing a layer that every production app needs, whoever or whatever wrote it. For more on where AI speeds work up and where it doesn’t, see vibe coding: realistic gains.

Harden or rewrite: how do I decide?

Hardening means keeping the app and adding what production needs: access rules, backups, safe payments, tests and a proper deploy. A rewrite means building a new app from scratch and moving users onto it.

The position behind the first rows is old and well tested. Joel Spolsky called rewriting working code from scratch “the single worst strategic mistake that any software company can make” (Joel on Software, 2000). His reason: old code carries every bug fix that real use taught you, and a rewrite throws that knowledge away. Martin Fowler’s “strangler fig” approach is the practical version: grow the new parts around the old system and retire the old pieces only once the new ones work (martinfowler.com).

For an AI-built app with paying users, the knowledge that matters is in the screens and flows. Customers have already told you, by paying, that those work. The weak part is underneath, and you can replace it without them noticing.

An example from practice: five months quoted, about four weeks done

A non-technical founder had built the product with an AI app builder and had around 300 paying users. Something broke every week. Two agencies, looking at code they hadn’t written, both quoted a full rewrite: five months before any new feature.

On closer look, the screens and flows were the valuable part. The risk sat underneath:

• any logged-in user could open another customer’s records by changing a number in the address bar;
• there were no backups;
• a payment request that timed out and was retried could charge the same card twice.

The founder chose to keep the interface customers knew, and we rebuilt what was underneath in order of risk: data access rules on day one, backups in the first week, then payments made safe to retry, then a proper repository with tests and one-click deploys.

It took about four weeks. There was no migration day the users ever noticed, and the founder kept shipping features the whole time.

What should be fixed first?

Order by “what could hurt customers or the business most if it happened tonight”, not by how ugly the code looks.

1. Data access. Can one user read or change another user’s data? This is the hole that has already exposed real users of AI-built apps. In 2025 researchers scanned 1,645 apps built with Lovable and found that 170 of them let anyone access information about the site’s users (Semafor, 2025). The cause was missing database access rules (row-level security, rules that say which rows each user may see), recorded as CVE-2025-48757. Lovable disputes the CVE, saying each customer is responsible for protecting their own app’s data, which is exactly why this check is on you. Supabase’s own docs are blunt: “A table in an exposed schema without RLS is readable and writable by any role with a grant on it” (Supabase docs).
2. Backups. If the database were wiped today, what would you restore from? Until someone has actually restored a backup once, you don’t know that it works.
3. Secret keys. Payment and AI provider keys must live on the server, never in code sent to the browser.
4. Payments. A network hiccup happens; the question is whether a retry charges twice. Stripe supports this directly: idempotency keys let you retry “without accidentally performing the same operation twice” (Stripe API docs).
5. Code and deploys. The code goes into a repository your company owns, with tests for the money paths and a deploy that can be rolled back in one click. This is where “keeps breaking” stops.
6. Monitoring. You hear about errors from an alert, not from a customer email.

Only after these does it make sense to talk about cleaner architecture or performance.

What can I check myself in 15 minutes?

You don’t need to read code for these.

• The URL test. Log in as a test user, open a record, and change the number or ID in the address bar. If you see someone else’s data, stop adding features: fix this first.
• The Supabase check. If your app uses Supabase, open the dashboard and look for tables where row-level security (RLS) is turned off.
• The backup question. Ask whoever can access the database: where are backups, how old is the newest, and when was one last restored?
• The accounts list. Write down every account the app depends on: code repository, database, hosting, domain, Stripe, AI provider. Next to each, write whose email owns it. Anything not owned by your company is a risk.
• The double-charge test. Ask your developer, or the tool’s chat, one plain question: “What happens if a payment request times out and the user clicks again?”

If all five come back clean, the remaining work is mostly tests and deploys, and the case for a rewrite gets much weaker.

How much does making it production-ready cost?

There’s no honest single number, because the cost depends on what the checks above find. What drives it:

• How many of the six areas are missing. Fixing data access alone is a different job from fixing all six.
• Where the data lives. A real database you can move to your own account is the cheap case. Data that has to be restructured or migrated is the expensive one.
• How much of the logic sits in the browser. Everything that enforces a rule must move to the server.
• Whether you keep shipping features during the work. You should, but it adds coordination.

In the example above, the agencies quoted five months of rewrite and the hardening took about four weeks. Public numbers from elsewhere are scarce. On Hacker News, one developer described quoting a client $43k to refactor a SaaS built with Cursor that had reached $11k in monthly revenue within six weeks (Hacker News). That is one anonymous post about a different job, not a market rate.

The useful way to buy this work is in two steps: first a short review that produces a ranked list of risks, then a quote for fixing them in that order. A single big number without a list behind it tells you nothing about what you are paying for. The same logic applies to any estimate; see how estimation works.

An agency says rewrite. What should I ask?

A rewrite proposal isn’t automatically wrong, but it should survive these questions:

• Which specific problems can’t be fixed in the current code, and why?
• What happens to my users on migration day? Who moves their data, accounts and subscriptions?
• When do I get the first new feature, in weeks from signing?
• Can you fix data access and backups in the first week, whatever we decide about the rest?
• Who will own the new repository and cloud accounts?
• If we stop halfway, what do I have?

If the answers stay vague, get a second opinion before signing. A written review of the app and the quote is a small step next to five months of the wrong project. More red flags when choosing a team are in how to choose a developer.

When is a rewrite the right call?

Sometimes it is. The honest cases:

• the app has no server of its own and stores data in the browser;
• the product is pivoting, and most current screens won’t be used;
• the platform won’t let you export the code or move the data;
• only a couple of parts cause the trouble, in which case replace just those, one at a time, with the old version running until the new one matches.

Even then, the existing app is your best specification. It shows what customers actually use, which is more than any document will.

What I’d do in your place

1. Run the URL test and the Supabase check today. If either fails, fix data access before anything else.
2. Make sure a backup exists and someone has restored it once.
3. Move every account (code, database, hosting, domain, Stripe) to your company’s name.
4. Get a ranked list of risks before you get a price. Fix in the order of that list while you keep shipping features.
5. Bring in someone senior for the first month, so the foundations get built once. That is the job of a fractional CTO: technical decisions made on your side of the table, with the code and accounts staying yours.

Tell me what your app does and what keeps breaking, and I'll reply in writing with where I'd start.

Free consultation