Rescue & takeover
Your build never reached production. In days, at a fixed price, we read the code and the cloud accounts and give you a written verdict (finish, harden or rewrite), each with a cost and a date. Then we do the work, or you take the verdict to whoever you choose.
| 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. If most of the existing code is not worth keeping, the verdict says that.
The production gap, itemised
Auth, data model, migrations, tests, error handling, payments, secrets, backups and deploys, each marked 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 continue with us.
Why do software builds stall before production?
Almost always for one of five ordinary reasons, and none of them make the project a write-off.
- The demo was never hardened. It worked on a laptop, with one user and no real data. The distance from there to production is most of the work, and nobody scoped it.
- Nobody could review the generated code. An agent produced a working-looking codebase faster than the team could read it. The gaps are the quiet ones: unhandled errors, an auth check 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 got postponed.
- Nobody understands the codebase now. Whoever held it in their head has left, or nobody ever did.
- The vendor is gone. The relationship ended, or the budget did, and you hold a repository nobody can explain.
What you need first is a read of what is actually there, not another quote for the remaining features.
What the assessment gives you
A written verdict a non-engineer can act on and an engineer can argue with: finish, harden or rewrite, with a cost and a timeline against each.
Behind the verdict is the inventory. What is built and works. What appears built and does not. What is missing outright. What works today and will fail later. If the answer is rewrite, it names what is still worth keeping: the schema, the domain logic, the design, the specification implicit in the code. If the answer is to stop altogether, that costs you the assessment rather than another two quarters.
To get there we take the repository, the cloud accounts and whatever documentation exists, and get the thing running. Then we go through the data model, the auth and permission boundaries, the error paths, what the tests really assert, how secrets and environments are handled, what deploying involves, and who owns each third-party account. Where the code and the previous team's estimate disagree, the assessment says which one we believe and why.
Why it takes days, not weeks
We write most of our own code with agents and review all of it, so we know where generated code holds up and where it leaves holes. Reading an unfamiliar hundred-thousand-line codebase quickly is the same skill pointed the other way. We are not sceptical of the tools that produced your build, only of code nobody checked.
After the assessment: finish, harden or rebuild
Each is quoted separately once the assessment shows which one you need.
Finish it. The architecture holds and the production half is missing. Auth, data, billing, tests, deploys and error paths, until real users can be pointed at it.
Harden it. It is live and fragile. Monitoring, the failure cases, the security basics, and deploys that are routine instead of an event.
Rebuild it. The existing product becomes the specification for a new one, which is a considerable head start: you have already watched a version of it not work.
In all three you own the result, and the handover is written so your own team, or the next one you hire, can take it from us.
When a rescue is the wrong call
- Your team is intact and the build is moving: you want a second opinion, which is consultancy.
- Little exists beyond a prototype and some screens: start clean with an MVP in a week.
- The product works but falls over: that is platform and infrastructure.
- The previous vendor is still engaged and doing reasonable work: keep them. Switching mid-build has a real cost.
We don't know whether the code is any good. Can you tell us?
That is what the assessment is for, and why it is a separate, fixed-price step. We read the codebase, run it, and write down what is real. You keep that answer even if it ends the conversation.
It was built with AI. Is that a problem?
Not on its own. Plenty of agent-written code is fine. The problem is generated code nobody 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 the assessment recommends a rewrite and shows the reasoning, even though that costs us the larger finishing engagement. Using the existing product as the specification often makes a rewrite faster and cheaper than untangling what is there.
What if it is mostly fine?
That happens, 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 reached.
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 they disagree with the documentation, the code wins.
Can you work with whoever built it?
Yes, if they are still around. Half an hour with the person who wrote it is worth a day of reading.
Will you finish it, or only tell us what is wrong?
Either. The assessment is priced on its own, so you are not buying a build to find out whether you should. Most assessments turn into the work that follows.
How long does the assessment take?
Days, not weeks, for most codebases, at a fixed price agreed before it starts. 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 moving repositories, cloud accounts and vendor logins into your name, because in stalled builds they are often scattered across people who have left.
Tell us where the build stopped.
A few lines on what was built, who built it and where it stalled. Within one business day you get a fixed price and a start date for the assessment.