Service
The build is 70% done and it has been 70% done for four months.
Inherited codebases, stalled AI-tool MVPs, and the contractor who understood it and left. We find out what is actually wrong, tell you plainly, and then fix it.
The problem
What this actually looks like
Somebody built most of it. Maybe an agency, maybe a contractor who has moved on, maybe an AI coding tool that got you further than you expected and then hit a wall it could not see.
Every estimate for finishing it comes back longer than the last one. Nobody can tell you whether the problem is the plan, the people, or the architecture — and the people you are asking have an interest in the answer.
Meanwhile the demo still works, which makes it hard to explain to anyone why it is not shipping.
Deliverables
What you get
Concrete artifacts, not activities. Everything below is something you can point at and say you received it.
- A written assessment of what is actually wrong, in priority order
- A rebuild-versus-repair recommendation with the reasoning shown
- The critical path to a shippable state, with realistic dates
- A risk register: what breaks first, and what it takes down with it
- Working code, once you decide to proceed — not just a document
- Whatever we find, in writing, whether or not you hire us to fix it
Timeline
How it works
Ranges, not best cases. The dates below are what it usually takes, including the week something goes wrong.
- 01Day 1
NDA, repo access, environment
We get it running locally on day one. How long that takes is itself the first finding, and it is often the most revealing one.
- 02Days 2–4
Read everything, change nothing
Architecture, data model, dependencies, deploy path, test coverage. We are building an accurate picture before we have opinions about it.
- 03Days 5–8
Reproduce the failures
The bugs you can describe and the ones you have stopped mentioning because they seem unfixable. Both matter.
- 04Days 9–10
Report and walkthrough
Written findings, prioritised, with a repair-or-rebuild call and a number attached to each path. Then a call to argue with it.
- 05After
Fix it, or take the report elsewhere
The audit fee credits against a build if you proceed with us. If you take the report to another team instead, it still works — it is written to be useful, not to be a sales document.
Approach
How we think about this
We start by getting it running, because the gap between the README and reality is the fastest measure of how a codebase has been maintained. A project that takes two days to run locally will take two weeks to onboard anybody.
We do not recommend a rebuild by default. Rebuilds are the expensive answer that feels decisive, and roughly half the time the honest recommendation is that the architecture is fine and the problem is three specific things.
When AI-generated code is involved, the pattern is consistent: the happy path is complete and the seams are not. Auth, permissions, error states, migrations and anything requiring a decision across two files. That is where we look first.
What we refuse to do
- We will not quote a fix before reading the code. Anyone who does is guessing, and you will pay for the guess later.
- We will not recommend a rebuild to make the engagement bigger. It is in the report either way, with the reasoning shown so you can challenge it.
- We will not take over a codebase and then make ourselves the only people who understand it. That is the situation you are already in.
Engagement
How this is usually bought
Shape
Paid audit first, always
From
$2,400
demo figure
Fixed fee, ten working days, credited in full against a build if you proceed. This is the front door for almost every rescue.
Full pricingFAQ
Questions people actually ask
The last team told us it needs a full rebuild. Is that true?
Sometimes. Roughly half the time the architecture is survivable and the real problem is a short list of specific things, and the previous team was giving an honest answer to a question they had stopped being able to see clearly. The report shows the reasoning either way so you can push back on it.
It was built with Lovable, Bolt or Cursor. Is that a problem?
Not by itself, and we see it constantly. AI tools are good at the happy path and weak at the seams — permissions, error states, migrations, anything requiring a decision spanning several files. That is a known shape of problem, which makes it faster to assess than a codebase with a history nobody can explain.
What if you find nothing serious?
Then the report says so, you have the confidence you were paying for, and you should spend the build budget elsewhere. That is a good outcome and it happens more than you would think.
What if you find too much?
The report is prioritised precisely for that case: what has to be fixed to ship, what can wait, and what you can live with permanently. A hundred findings with no order is a document nobody acts on.
Do we have to hire you afterwards?
No, and the report is written to be useful to whoever does the work. If you take it to your in-house team or another agency, it will still make sense. The fee credits against a build only if you build with us.
Our previous developer is unreachable. Does that stop you?
No. That is the normal case rather than the exception, and it is why we read the code rather than interview the author. It does mean the first few days are slower, and the report will tell you honestly how much of the original intent was recoverable.