Harden or rebuild? What actually survives when an AI prototype goes to production
TL;DR
Harden-versus-rebuild is not one decision, it's one per layer. In practice the UI is 50–90% reusable, authentication is almost always replaced, the database is redesigned, and the app structure is refactored. Deciding per layer — rather than all-or-nothing — is what keeps this a weeks-long project instead of a year-long rebuild.
Every founder who brings us a Lovable, v0 or Bolt prototype asks a version of the same question: can you fix this, or do we start over?
It’s the right question at the wrong resolution. Asked about the whole codebase, both answers are wrong. “Harden it” ignores that some of what you have is structurally unsafe. “Rebuild it” throws away the part that’s genuinely valuable — and it’s usually the part you’d least expect a rewrite to spare.
Harden-versus-rebuild is not one decision. It’s one decision per layer.
The layers, and what usually happens to each
This is the pattern across the prototype rescues we and most teams doing this work keep landing on. It is remarkably consistent:
| Layer | Usual outcome | Why |
|---|---|---|
| UI / components | Mostly reused — roughly 50–90% survives | The generators are genuinely good here. Screens and flows are the thing they were optimised to produce. |
| App structure | Refactored | Generated code works but tends to sprawl: logic in components, no clear boundaries. Salvageable, not shippable. |
| Backend / business logic | Partially or fully rewritten | Happy-path only. The paths a demo never hits are the paths production lives on. |
| Authentication | Almost always replaced | Generated auth is typically a mock with the shape of a login. It looks right and holds nothing. |
| Database | Redesigned | Prototype schemas encode the demo, not the domain. Migrations, relationships and integrity are usually absent. |
Read the table again and notice what it says: the thing you can see is the thing you keep. The thing you can’t see is the thing you replace.
That’s not a coincidence. AI generators optimise for what’s demonstrable — the screen recording, the click-through, the moment it looks done. Everything that decides whether software survives contact with real users is invisible in exactly that frame.
You keep the shape, not the system.
Why “just rewrite it” is the expensive answer
The instinct to start clean is understandable and usually wrong, for a reason that has nothing to do with code.
Your prototype is a specification. Someone — probably you — made several hundred product decisions while iterating with the generator: this flow, not that one; this field on this screen; this state after that action. Those decisions are real design work, and they’re encoded in the UI you’re about to throw away. A from-scratch rebuild silently discards them and then rediscovers them, badly, over the following two months.
Keep the interface. It’s the artefact of your thinking.
Why “just harden it” is the dangerous answer
The opposite instinct fails harder, because the layers aren’t independent.
Generated auth isn’t weak; it’s frequently decorative — a login screen that gates the interface while the underlying data sits open. You cannot patch that. Bolting real authorisation onto a data model that was never designed with a notion of ownership means retrofitting “who is allowed to see this row” into a schema where the answer was always “everyone.” That’s a redesign wearing a patch’s clothing, and pretending otherwise is how a two-week hardening job turns into a two-month excavation.
If the data model has no concept of tenancy, the database is a rebuild. That decision cascades — and it’s better to know that in week one than to discover it in week six.
The order that works
The sequence matters as much as the calls, because each step makes the next one cheaper:
- Freeze features. You cannot rebuild a moving target, and the generator makes it very easy to keep moving.
- Get it into version control properly. Export from the generator, into a real repository, with history.
- Audit — security and structure. Where’s the data actually exposed? What’s the real architecture, as opposed to the intended one?
- Extract the backend and data model first. This is where the decisions cascade, so it’s where you need clarity before anything else is worth doing.
- Replace auth properly. Real identity, real authorisation, enforced server-side rather than hidden client-side.
- Add a staging environment. Somewhere that isn’t production to find out you were wrong.
- Add monitoring and logs. So you learn about breakage from your tooling and not from a customer.
- Then refactor the UI gradually — against a backend that’s now trustworthy.
Most teams instinctively start at step 8 because it’s the visible one. Starting there means refactoring an interface against a data model you’re about to change, which is work you will do twice.
What this buys you
Done in this order, prototype-to-production is a weeks-long project, not a year-long rebuild — because you’re not rewriting what already works, and you’re not hardening what can’t be hardened. You’re making the call per layer, in the order where each answer makes the next one cheaper.
And the thing that matters most on the other side: your first engineering hire inherits a codebase, not an archaeology dig.
The point
The question isn’t whether your prototype is good enough to keep. It’s which parts of it were ever the point. The screens were real work — keep them. The plumbing was never there — build it.
If you’re staring at a prototype and trying to make this call, book a call. An architecture audit is a short, cheap piece of work, and it’s a much better place to start than a decision made by instinct.