Rescue & takeover
Something got built and never made it to production. We read the codebase and the infrastructure, tell you what is actually there, and give you a straight answer on whether it should be finished, hardened or thrown away. Then we do that part.
| Engagement | Fixed-price assessment, then scoped work |
|---|---|
| Built for | Teams with a build that never reached production |
| Price | Quoted on scope |
A written assessment
What the code does, what it only appears to do, and what sits between it and production. Read from the repository and the cloud accounts, not from the last vendor's status report.
A verdict, with a number against it
Finish, harden or rewrite, each with a cost and a timeline, including the version where the honest answer is that most of the existing code is not worth keeping.
The production gap, itemised
Auth, data model, migrations, tests, error handling, payments, secrets, backups and deploys, listed one by one as done, half-done or absent. No summary adjectives.
Everything in your name
Repositories, cloud accounts, domains and third-party services moved into your ownership, whether or not you carry on with us afterwards.
Builds stall for a small number of reasons
Almost every stalled build we see is one of these, and none of them are exotic.
- The demo was never hardened. It worked on a laptop, in front of an audience, with one user and no real data. The distance between that and production is most of the work, and it is the part nobody scoped.
- Nobody could review the generated code. An agent produced a working-looking codebase faster than the team could read it. The gaps it left are the quiet ones: unhandled errors, an auth check that exists in one route and not the next, tests that assert nothing.
- The unglamorous half is missing. Auth, migrations, billing, permissions, backups, deploys. Features demo well and these do not, so these are what got postponed.
- Nobody understands the codebase now. Whoever held it in their head has left, or it was never held in anyone's head to begin with.
- The vendor is gone. Either the relationship ended badly or the engagement simply ran out, and you are holding a repository nobody can explain.
None of this makes the project a write-off. It does mean the first thing you need is an honest read, not another quote for the remaining features.
The assessment
We start by reading, because a quote written without reading the code is a guess dressed up as a number.
We take the repository, the cloud accounts and whatever documentation exists, and we get the thing running. Then we go through it: the data model and whether it fits what the product actually needs, the auth and permission boundaries, what happens on the error paths, which tests exist and what they really assert, how secrets and environments are handled, what deploying involves today, and which third-party services it depends on and who owns those accounts.
Where the code and the documentation disagree, we believe the code. Where the previous team's estimate and the code disagree, we tell you which one we believe and why.
What you get out of it
A written assessment, in plain language, that a non-engineer can act on and an engineer can argue with. What is built and works. What appears built and does not. What is missing outright. What will bite later even though it works today.
Then the part that matters: finish, harden, or rewrite, with a cost and a timeline against each. If the answer is rewrite, the assessment says so, and it says which parts of the existing work are still worth keeping — the schema, the domain logic, the design, the specification implicit in the code. Almost nothing is a total loss, and almost nothing is as complete as it looked.
If the honest answer is that you should stop altogether, you get that in writing too, and it costs you the assessment rather than another two quarters.
Why we can read it quickly
We are an AI-first studio. We write a lot of code with agents, review all of it, and have shipped large codebases that way, so we know exactly what generated code tends to do well and where it quietly leaves holes. Reading an unfamiliar hundred-thousand-line codebase fast is the same skill, pointed in the other direction.
That is the specific reason a build that stalled because it was generated faster than it could be reviewed is a problem we are equipped for. We are not sceptical of the tools that produced it. We are sceptical of code nobody checked, which is a different thing, and the fix is reading rather than starting over on principle.
Then we do the work
Most rescues turn into one of three shapes, quoted separately once we know which one you are in.
Finish it. The architecture holds and the remaining work is the production half. Auth, data, billing, tests, deploys, and the error paths, until it is something real users can be pointed at.
Harden it. It is already live and it is fragile. Monitoring, the failure cases, the security basics, and a deploy that is routine instead of an event.
Rebuild it. The existing product becomes the specification for a new one, which is a considerable head start. You know what you want because you have already watched a version of it not work.
In all three, you own the result and the handover is written so that your own team, or the next one you hire, can take it from us.
When to pick something else
- If your team is intact and the build is moving, you probably want a second opinion rather than a takeover. That is consultancy, and it costs a fraction of this.
- If almost nothing exists beyond a prototype and some screens, there may be nothing to rescue. Starting clean with an MVP in a week is usually faster and cheaper than assessing something that has not been built yet.
- If the product works and the trouble is that it falls over, that is platform and infrastructure, not a rescue.
- If the previous vendor is still engaged and doing reasonable work, keep them. Switching mid-build has a real cost, and we will say so rather than take the work.
We don't know whether the code is any good. Can you tell us?
That is the assessment, and it is the whole reason it exists as a separate, cheap step. We read the codebase, run it, and write down what is real. You get that answer even if it ends the conversation.
It was built with AI. Is that a problem?
Not on its own. Coding agents write conventional code, and plenty of it is fine. The problem is generated code that nobody on the project was in a position to review, so nothing caught the missing error handling, the auth check that was never wired up, or the migration that only ever ran on one laptop.
What if the answer is that we should start again?
Then we say so and show the reasoning. Sometimes a rewrite with the existing product as the specification is faster and cheaper than untangling what is there, and telling you that costs us the larger finishing engagement. It is still the answer we give.
What if it is mostly fine?
That happens too, and it is a good outcome. A build can be eighty percent there and stuck on a fortnight of unglamorous work — auth, migrations, error paths, a deploy pipeline — that the original team never got to.
The original developer or agency is gone. Does that stop you?
No. That is the normal case. We work from the code and the infrastructure, and where those disagree with the documentation, the code wins.
Can you work with whoever built it?
Gladly, if they are still around. Half an hour with the person who wrote it is worth a day of reading, and we would rather have them in the room than write around them.
Will you finish it, or only tell us what is wrong?
Either. Most assessments turn into the work that follows, but the assessment is priced and scoped on its own so you are not buying a build to find out whether you should.
How long does the assessment take?
Days, not weeks, for most codebases. It is quoted as a fixed price before it starts, and it is small next to what finishing the build costs.
Who owns it at the end?
You do, throughout. Part of the first week is getting the repositories, cloud accounts and vendor logins into your name, because in stalled builds those are often still scattered across people who have left.
Tell us the one thing it has to do.
If it's sharp enough to prove in a week, we'll say so and give you a date. If it isn't, we'll tell you that too, along with what we'd build first instead.