Situation 02 · /half-built
Something got built. It isn't finished, and nobody wants to say so.
A freelancer went quiet, an agency ran out of budget, or an AI tool got you most of the way over a weekend. I audit what exists, tell you plainly what is worth keeping, and finish it so your business can rely on it.
Sound familiar?
Five ways this shows up
- The developer who built it stopped answering, and nobody else has the passwords, the code, or the patience to reconstruct either.
- It demos beautifully and fails quietly. There is no error reporting, so the first person to find a bug is always a customer.
- You built it yourself with an AI tool, and it genuinely works, on your laptop, for you, on a good day. You know that is not the same as done.
- Every small change breaks something unrelated, and each fix costs more than the last one did.
- You cannot decide whether to finish it or start over, and everyone you ask has an incentive baked into their answer.
Recognize yours?
What I typically inherit
The agency handoff
Built to the contract, finished to the budget. It demos well; the last 20% was quietly descoped meeting by meeting.
Becomes Every one of them gets the same treatment: audited, given verdicts in writing, and finished by the person who wrote the verdicts.
The freelancer's repo
The developer went quiet, and the code, the passwords, and the hosting live wherever they left them.
Becomes Every one of them gets the same treatment: audited, given verdicts in writing, and finished by the person who wrote the verdicts.
The AI prototype
Genuinely works, on your laptop, for you, on a good day. No auth, no error reporting, no backups, no deploy.
Becomes Every one of them gets the same treatment: audited, given verdicts in writing, and finished by the person who wrote the verdicts.
The v1 that grew
A real product carrying years of patches, where every change breaks something unrelated.
Becomes Every one of them gets the same treatment: audited, given verdicts in writing, and finished by the person who wrote the verdicts.
Yours isn't here?
Every operation has its own version of this. Describe yours, and I will tell you what it would become.
Show me what you've got →What I do about it
Audited first, then finished, then handed over
A rescue starts with an audit, not a rewrite. I read the code, run it, and map what actually exists against what you were promised. Every module gets a verdict: keep, fix, or replace. That audit is the first week of the two to three week scope stage, fixed price, and you get the findings in writing whatever you decide next.
The decision memo answers the question you actually have: finish or start over. It answers with numbers, an estimate for each path, and the reasoning, because "always rewrite" is what developers say when they have not read the code, and "always salvageable" is what they say when they are billing hourly.
Then I do the unglamorous work that turns a prototype into a product: tests around the parts that matter, authentication that would survive an audit, error reporting, backups, deployment that does not need the original author awake. The feature list barely grows. The reliability does. And the verdicts are commitments, not opinions: the person who audited the code is the person finishing it.
wk 1 audit, wk 2 verdicts and architecture, wk 3 estimates and memo
- codebase audit with keep/fix/replace verdicts
- finish-vs-restart memo with an estimate for each path
- risk register
- production-readiness backlog
- handover documentation
staged, riskiest module first
deployed, documented, accounts in your name
Fair questions
Asked by almost everyone in this situation
Will you just tell me to rewrite it?
Only if the numbers say so, and the memo will show you the numbers for both paths. Rewrites are recommended far more often than they are warranted. Most half-built systems have a salvageable core wrapped in fixable problems.
It came out of an AI tool. Is that a problem?
No, and you are not alone; a growing share of rescues start exactly there. AI-built prototypes are legitimate raw material, and the working functionality you built gets preserved, not thrown away. What these prototypes reliably lack is the production layer: security, error handling, data integrity, deployment. That layer is exactly what the audit scopes and the finish delivers, on infrastructure you control.
The old developer is gone. Can you work without them?
Yes. Code, hosting, and data tell the story on their own. Part of every rescue is making sure you are never in this position again: passwords in your accounts, code in your repository, documentation a stranger could pick up.
What if I only want the audit?
Then you stop after the scope stage. The findings, the verdicts, and the finish-versus-restart memo are in writing and they are yours, whoever does the finishing. Most clients have the auditor finish it, because every verdict in the memo is something I then have to stand behind in code.
Show me what you're sitting on.
A link, a repo, or just the story of how it stalled. I will tell you within days whether it is worth finishing, and what that would take.
Start a conversation