Rewrite or rescue? Buy a written verdict before you buy a fix

Founders who built an MVP in Lovable, Bolt or Cursor rarely call anyone on the day the app breaks. They call later, when the credits, the patience or the confidence run out. And they bring one question they cannot judge on their own: rewrite or rescue?

Our answer: the first useful thing to buy is not a fix. It is a written verdict. What is there, what is broken, which path is cheaper, in a document a co-founder can read without opening the code. A quote to “fix a few things” answers a question nobody asked.

What the rescue shops report

Several studios that sell rescue work have published their numbers. They sell the service, so their frequencies are their claims, not a census.

• Eight Bit Studios reviewed 100 vibe-coded apps and listed the failure modes. Number 8 is the founder who “runs out of credits, patience, or confidence”, which they call “the conversion point for every other failure mode”. Number 9 is decision paralysis: “rewrite or rescue?” By their account it comes up in most first conversations.
• JetThoughts wrote up 14 rescue projects over six quarters. One MVP cost $28K. Six weeks after launch it had 4% test coverage, an SQL injection and three different implementations of the same conflict check. The repair took the total to $89K. Their reading of the market: the way in is now an audit, with a fixed price after it.
• A technical co-founder who built a backend by prompting wrote publicly about an incident. Their voice provider went silent for 94 minutes. There was no alert and no fallback path. Afterwards the other co-founders stopped trusting the tech. In our paraphrase, the lesson they drew was that they never knew the moment the system had become harder than they could handle.
• A competitor, at governanceai.io, sells rescue as a package: a free written diagnosis, then a rebuild of one component against a metric, with the build fee at risk. The code and the documentation stay with the client whatever the outcome.

Our reading of the four together: the incident is not what makes a founder buy. Losing the ability to judge is. And the comparison a founder will make already includes a written verdict before any build.

Why a verdict, not a quote

A quote to fix a few things assumes the founder already knows what is broken. If they knew, they would not be stuck between rewrite and rescue. That is our view, and it is the core of this piece.

The co-founder's case shows what is actually being bought. Not code. A document they can put in front of partners who stopped trusting the tech.

The $28K MVP shows what skipping the read costs. Three implementations of one check is not a bug you fix once. It is a rule you have to find three times, and the third copy is the one that bites later. The first half of that is JetThoughts' finding; the second half is our opinion.

Four checks before you pay anyone

In our view these four come first. None of them needs you to trust whoever runs them, and each one produces a line a non-engineer can read.

1. Do the tests exist, and do they test anything?

# coverage, as a number
npm test -- --coverage        # JS / TS
pytest --cov=app              # Python

# the line that goes in the verdict
coverage: __%    critical paths with a test: __ of __

Coverage alone flatters. The narrower question is the useful one: does the path that takes money, books a slot or sends a message have a test that fails when it breaks?

2. Is each business rule implemented once?

Search for a rule by the words people use for it, not by function name.

grep -rniE "overlap|conflict|already booked" src/
grep -rniE "overlap|conflict|already booked" src/ | wc -l

# the line that goes in the verdict
rule: ______    implementations: __    files: ______

If one rule lives in three places, the three will drift. That is the conflict-check finding in the JetThoughts example, and it is cheap to look for.

3. Are queries built from strings?

# JS / TS: SQL assembled with template strings
grep -rnE "(SELECT|INSERT|UPDATE|DELETE).*[$][{]" src/

# Python: SQL assembled with f-strings
grep -rnF 'execute(f"' app/

A hit is not proof of an injection. It is a line someone has to read. In the $28K MVP, an SQL injection was one of the findings.

4. When a provider goes quiet, who finds out?

provider:            ______   (voice / LLM / payments / email)
health check:        every __ min
alert goes to:       ______
fallback when down:  ______   (front desk / queue / message to the user)
last tested:         ______

In the 94-minute incident, the alert line and the fallback line would both have been blank. The form is five lines. Filling it in honestly is the work.

What the verdict looks like

This is the shape we think the first deliverable should take. One page, written for the person who has to decide, not for the person who has to code.

VERDICT: <product>, <date>

Recommendation:  rescue | rewrite parts | rewrite
Why, in one paragraph: ...

Findings
  1. Tests:              coverage __%, critical paths covered __ of __
  2. Duplicated rules:   __  (list)
  3. String-built SQL:   __  (files)
  4. Silent providers:   __  (no alert / no fallback)

First move:        one component, one metric, one edge
Leave alone:       ...
Breaks next if nothing is done:  ...
Who owns the code and this document:  ...

The trade-off, named. A verdict is slower than a quote. And it can say “rewrite”, which nobody wants to hear after spending the money once. We still think it is the right first step, because a fix bought without one is a guess with an invoice attached.

What would change our mind: data showing that founders who bought a quick fix stayed out of the rescue loop as often as founders who started with a written read. We have not seen that data, and we have not seen the vendors above publish it.

FAQ

Is “rewrite or rescue” really the main question? The vendors who sell rescue say it comes up in most first conversations. That is their claim, from their own pipeline. In our view it is the right question, usually asked late.

Can I run these checks myself? Yes. The commands above run on a typical JS/TS or Python repository; adjust the paths to yours. The harder part is judging what the hits mean, and writing it down so someone else can act on it.

Why not ask the AI tool that built the app to audit it? It can run the same searches. In our view the catch is the questions: a tool adds alerts and fallbacks when someone knows to ask for them, and the co-founder in the incident above did not know the moment they were needed. A blind spot you do not know about is not one you can ask about.

Does a verdict usually end in a rewrite? Not necessarily. JetThoughts and the governanceai.io offer both start from a diagnosis and then scope a defined piece of work after it. A good verdict says what to leave alone as clearly as what to replace.

A related case

In Holt, our language-learning product, quality is gated rather than asserted: content is checked against blind golden sets judged by a model with no hand in the material. The case: iloblique.com/holt.

If you have something worth building, we'd like to hear about it.

Sources

• Eight Bit Studios: review of 100 vibe-coded apps, failure modes 8 and 9.
• JetThoughts: 14 rescue projects over six quarters.
• governanceai.io, AI project rescue offer: https://governanceai.io/ai-project-rescue
• A technical co-founder's public incident post, September 2026. Paraphrased and not linked, to keep the author anonymous.