Rebuild or Harden? Deciding What to Do With a Vibe-Coded App

Somebody senior looked at your AI-generated codebase and said it should be rewritten. Somebody else said that would be insane. Both of them were confident, and neither gave you a test you could apply.

Here is the test. It is not about code quality, because AI-generated code quality is unremarkable — it is average code, written quickly, with the boring parts missing. It is about whether the shape of the thing can hold the product you are building.

Start from harden, and make rebuild earn it

The default should be repair, for a reason that has nothing to do with sentiment. In a vibe-coded app, the parts the AI did well are the parts a rebuild throws away: screens, flows, copy, the hundred small product decisions you made by looking at something and saying "no, like this." The parts that are missing — enforced authorization, constraints, migrations, error paths, deployment — are additive. You can install them under a working product without re-deriving the product.

A rewrite inverts that. You pay again for everything that already works in order to obtain things you could have bolted on, and during the months it takes you ship nothing. The classic failure is the six-week rewrite that hits month five while the old app, still in production, still needs fixes.

So: repair unless one of four things is true.

The four conditions that justify a rebuild

1. The data model cannot represent your product

This is the real one. If there is no tenant or organization concept and you sell to teams, if a subscription's lifecycle is a single boolean, if the same fact is stored in four places and they disagree, then no amount of hardening helps. Every feature you add fights the schema, and every bug fix creates two more.

Note the wording: cannot represent, not messy. A messy schema with missing indexes is a week of work. A schema with no concept of who owns a row is a different app. Fixing the fixable version is repairing the data model an AI gave you; the unfixable version is a rebuild of the backend.

2. You cannot get the code out

If your app lives on a platform with a proprietary runtime and no meaningful export, "hardening" is not available to you at any price, because nobody can change what they cannot read. Your choice is stay and accept the platform's limits, or rebuild elsewhere. The decision is about the platform, not the code.

3. The security model is inverted, not just leaky

Leaky means some endpoints forgot to check permissions. Inverted means the client is the authority — the browser decides what plan the user is on, what data to request, what role it has, and the server complies. Patching an inverted model endpoint by endpoint leaves you unsure you got them all, and you will not know when you missed one. Replacing the access layer wholesale is usually faster and always more verifiable.

4. The runtime cost per user is structurally wrong

Some generated apps make a paid API call on every keystroke, refetch entire tables to display a count, or run an LLM call where a lookup would do. If the unit economics only work at prices customers will not pay, that is architecture, not tuning. It is worth being honest about which one you have — many "we must rebuild, it is too expensive" cases turn out to be a missing cache and a runaway effect hook.

What a rebuild should actually mean

Almost never "start an empty repository." In practice a good rebuild is one of these:

• Backend replacement. Keep the frontend, build a real API and schema behind it, migrate data, cut over. Two to four weeks for a typical MVP, and the product your users see does not change.
• Access layer replacement. Keep everything, put a single enforced authorization boundary in front of the data, and route all reads and writes through it.
• Strangler migration. Stand up the new implementation beside the old one and move one route at a time behind a flag, so you can stop at any point and are never holding two half-working systems in your head.

All three are incremental and reversible. That property matters more than the technology choice, and it is what separates a rebuild that ships from a rewrite that becomes folklore.

The comparison, in numbers

Full-cost detail sits in what it costs to take a vibe-coded app to production. The pattern in that table is consistent across engagements: the middle column is where most apps that need more than hardening actually belong, and the right column is where founders think they belong before someone reads the code.

Two failure modes to avoid

Rebuilding because the code is ugly. Ugly code that works and is safe is a maintenance annoyance, not a business risk. Ranking your problems by severity rather than by how much they irritate you is most of what a technical debt strategy is.

Hardening a foundation you already know is wrong. The mirror image. If you have concluded the schema cannot support multi-tenancy, adding tests and constraints around it is money spent on something you will delete. Do the structural fix first, then harden the result — the sequencing for that case is in retrofitting multi-tenancy.

How to decide in a week

Spend a few days on this, not a few weeks. Answer four questions with evidence: can you model your next twelve months of features in the current schema, can you export and run the code outside the builder, is authorization enforced server-side anywhere, and what is your cost per active user today. Two or more of those going badly points to a targeted rebuild of that layer. All four fine means you are hardening, and the work ahead is careful refactoring rather than replacement.

Frequently asked questions

Can I rebuild with AI tools again, faster this time? Yes, and many rebuilds are done exactly that way — but with a specification, a schema designed first, and review at each step. The tools are not the problem; unreviewed autonomous generation against no design is. A second pass with the same process gives you a second app with the same gaps.

What do I do with the old app during a rebuild? Keep it running, freeze features in the area being replaced, and cut over per route or per module. If you cannot cut over incrementally, your rebuild is too coarse — split it until you can.

How do I know the rebuild is actually better? Define it before starting. Two accounts cannot see each other's data, every table has constraints, migrations exist, the deploy has a rollback, and cost per user is under a stated number. If you cannot name the criteria, you are not rebuilding for a reason, you are rebuilding for a feeling.

---

If you have two engineers giving you opposite advice and no way to arbitrate, the missing input is a read of the actual code. SprintX audits AI-built apps and returns a straight recommendation — harden, replace one layer, or rebuild — with the cost of each. Send us your repo.