Fix, harden or rebuild? How we decide

We decide by reading your code and asking one question per finding: can this be made safe where it stands, and if most of the answers are yes, we fix or harden rather than rebuild.

What is the difference between fixing, hardening and rebuilding?

These three words get used loosely, so here is what we mean by each.

Fixing means closing the specific problems that block launch or are hurting you now. One customer can see another customer's data. A key is visible in the page source. Payments succeed but the app doesn't update. This is a stabilisation sprint: one to two weeks, from $2,500.

Hardening means fixing those problems and then building the foundation that stops them coming back. That covers row-level permissions, secrets and environment separation, migrations and backups, failure handling and retries that are safe to repeat, automated tests around money and data, CI with one-step rollback, error tracking and cost monitoring. This is a production hardening sprint: three to five weeks, from $6,000.

Rebuilding means starting a new codebase and moving your users and data across. It is the most expensive option, the slowest, and the one with the most new risk. Rebuilding is not something we sell as a service. If it is the honest answer, the triage or audit tells you, and explains why.

Why is a rebuild so rarely the right answer?

Because the code you have already does something valuable: it works for your users in most of the cases that matter. A rebuild throws that away and replaces it with code that has never met a real user. The new version will have its own bugs, and you will find them the same way you found the old ones.

Most of the problems in AI-built apps are not in the parts people see. They are in what is missing: permission checks, migrations, tests, monitoring, rollback. You can add missing things to an existing app. That is what rescue means: keeping what works and fixing what doesn't.

How do we actually make the call?

It starts with reading. In a two-day triage for $349, a senior engineer reads your repository and hosting setup and returns the five risks most likely to hurt you first, an indicative range for fixing them, and a recommendation: fix, harden fully, or in rare cases rebuild.

If you need a fixed quote rather than a range, or real users, payments or sensitive data are already live, the Production Readiness Audit goes further. It takes five working days, costs $1,500, and scores twelve domains: architecture, authentication, authorisation, data, security, reliability, testing, performance, AI features, observability, deployment and cost. You get a scored report, a prioritised risk register and a fixed-price remediation proposal.

For each finding we ask the same things. Can it be fixed in place? Does fixing it touch one part of the code or all of it? Is the data model sound enough to build on? The pattern of answers across all twelve domains makes the decision, not a feeling about the code.

When is fixing enough?

Fixing is enough when the problems are few and specific, and the app is not yet carrying much weight. For example, an app with a small number of early users, one exposed key, a missing permission check on two tables and no tests around sign-up. Closing those findings lets you launch safely. You can harden further once there is revenue to justify it.

When do you need full hardening?

You need hardening when real money or sensitive data is moving, or when you plan to grow quickly. In those cases the absence of backups, tests and rollback is itself the risk, even if nothing has gone wrong yet. Hardening turns "it works" into "it works, and we'll know within minutes if it stops".

Hardening is also the answer when the same kind of problem keeps appearing. If every new feature breaks an old one, the issue is usually missing tests and no clear boundaries between parts of the system. That is common in apps written quickly with heavy AI assistance, including apps where a developer used Cursor for most of the work. Our page on fixing an app built with Cursor covers what we usually look for there, such as the same logic written in three places and code that looks confident but nobody has read.

What would make us recommend a rebuild?

A rebuild is rare, and we only recommend one when the findings point there together, not one at a time. Signs that can point that way include:

• The data model is wrong at its core, so every feature built on it inherits the same error, and migrating it would touch nearly every file.
• Business logic is spread and duplicated so widely that no one change can be made safely, and tests can't be added without rewriting what they test.
• The app is locked into a platform or service that can't meet a hard requirement you have, and moving it would change most of the code anyway.
• The app is still a prototype with few users and little data, so starting again costs less than it seems.

Even then, a rebuild rarely means starting from nothing. Screens, flows, copy and much of the logic can often be carried across. And sometimes the better answer is not a rebuild at all but a migration: moving the codebase off the builder to a standard repository, hosting and database you control, without rewriting it.

Whatever we recommend, the report says why, finding by finding.

What happens after the decision?

If you proceed within 30 days, half the triage or audit fee is credited against the sprint that follows. The sprint has a fixed scope and a written not-included list, and it is delivered to production, not to a staging branch. If you want us to keep owning reliability afterwards, managed AI engineering starts from $1,500 a month with a three-month minimum.

You can read the full AI product rescue offer, including what is not included, before you book anything.