Fledgeling · Software recovery
The app that comes after your vibe-coded app.
The prototype did its job. It proved the idea, it got you the demo, and it probably got you real users. Then it started falling over, and the thing that made it quick to build is the thing making it slow to fix. I rebuild it: same product, to a standard that survives contact with people.
Fixed scope, quoted before anything starts. The audit is a flat fee and comes back within a week.
You already know which of these is yours.
None of this is a criticism of how it got built. Every one is the predictable cost of shipping something fast enough to find out whether it mattered, and finding out was the right call.
There are tests, and not one of them can fail.
A suite that stays green on a deliberately broken build is not coverage, it is decoration. Usually it is assertions on things that were always true: the element exists, the function returns, the response was a 200.
The auth holds because nobody has pushed on it.
The happy path was the spec, so the checks live in the component that renders the button rather than on the route that does the work. It survives your demo and not a curious user.
The schema grew one field at a time.
Nothing enforces a shape at the boundary, so a bad row is one odd request away, and the code that reads it has to guess what previous versions of the code meant.
Every fix breaks something two files away.
Logic got copied rather than shared, because copying is what a model does when it cannot see the whole repo at once. Now there are four versions of the same rule and three of them are stale.
The secrets went out in the bundle.
It works, which is exactly the problem: a key that reaches the browser is a key you have already published, and rotating it does not undo that.
Nobody can tell you what is actually finished.
The board says shipped, the demo works, and neither of those is evidence. Ask which features have ever been exercised by anything other than a person clicking through the happy path, and the honest answer is usually nobody knows.
Where it starts
The first deliverable is an honest count.
Before anything gets rebuilt, the codebase gets reconciled against its own promises. The classes are a total partition, so every feature lands in exactly one and none can go missing between them.
Most people expect the bad news to be the broken column. It almost never is. It is the band of work that was never checked either way, which is invisible in a green build and is the thing that breaks a rebuild halfway through.
What the ledger found on real repositories →- Built and proven11
- Never measured46
- Measured and broken9
- Claimed, never built14
- Built, never named4
The 46 in the middle are the reason a rebuild goes wrong. They are not failures; nobody ever checked them either way, and a report that quietly drops them calls a half-finished product finished.
Six stages, and a gate on each one.
The same pipeline that built 45 products, pointed at your repository instead of mine.
- 01
ReckonFind out what is actually true.
Every feature the repo claims, on one side. Everything any test, run or trace actually proves, on the other. Each item resolves into exactly one class of a total partition, so nothing can fall out of the list. You get that ledger whether or not you go any further.
- 02
PlanDecide what to keep.
Not everything needs rebuilding, and a rewrite is usually the expensive wrong answer. The plan is grounded in the code that exists, names the seams the tests will hang off, and gets reviewed by a model from a different family before anyone writes anything.
- 03
BuildRebuild it in slices, in isolation.
Work fans out across agents on file-disjoint slices in separate worktrees, with a typecheck gate between each one. Slices land on a branch and rebase onto your trunk, so your main branch is never the place experiments happen.
- 04
ProveMake every test earn its green.
Each case names the mistake it would catch, and a case that cannot fail is treated as a defect rather than as coverage. Each requirement records which rung of evidence it stands on, so a critical flow proved only by the button rendering does not pass.
- 05
GradeHave someone else mark the homework.
The work is graded in fresh context by a model from a different family than the one that built it, against the original requirements rather than against the plan. It passes or it comes back as a work order. There is no third option.
- 06
Hand backLeave you able to keep going.
You get the repository, the ledger, the suite, and the gates that keep it honest, wired into your own push hook. The point is that the next feature is yours to ship, not another engagement.
Why trust the method
It was built on my own repositories first.
45 products run through these gates, 14 of them shipped and installable today. The gates were not designed for a pitch deck; they exist because they caught things in my own code that I would otherwise have shipped.
- Warden
- MCP Router
- Dossier
- Splice
- Scrim
- Orderly
- Proctor
- Ledger
- Sift for Mail
- Egress
- Tandem
- Loupe
The engagement ladder
Fixed scope, priced before we start.
No open-ended hourly work. Each rung has a defined output and a price, and each one is worth having on its own if you stop there.
The Reckoning
An honest count of what your codebase actually proves.
Fixed fee
Back within a week
- ✓ Every claimed feature resolved into one class of a total partition
- ✓ The band nobody ever checked, named and sized
- ✓ Secrets, boundary and auth exposure walked and listed
- ✓ A rebuild plan ordered by what is actually costing you
- ✓ A fixed quote for the rebuild, derived from the findings
Recovery Sprint
The critical path rebuilt, gated, and handed back on your trunk.
Fixed quote, from the audit
Two to four weeks
- ✓ The paths that break rebuilt in file-disjoint slices
- ✓ A suite where every case names the mistake it catches
- ✓ Boundary schemas, real auth, secrets off the client
- ✓ Every slice graded out-of-family before it merges
- ✓ Push gates wired into your own repository
- ✓ A write-up of what changed and what was left alone
Fleet Advisory
Run the method yourself, on your own team's repositories.
Monthly retainer
Monthly, cancel any time
- ✓ A model and effort routing policy measured on your codebase
- ✓ Worktree isolation and multi-agent supervision set up
- ✓ Out-of-family review wired into your pull requests
- ✓ A private benchmark built from your own merged PRs
- ✓ Two working sessions a month with your engineers
A rebuild is quoted from the audit, so the number you get is based on what the ledger actually found rather than on a guess made before anyone opened the repository. Ask for the figures and you get them the same day.
Before you get in touch
When this is the wrong call.
If the idea is not proven yet, keep vibe coding. Hardening a product nobody has chosen is an expensive way to find out they were not going to. Come back when the falling over is costing you something.
If you want it rewritten from scratch, that is usually the wrong answer and I will say so. A rewrite throws away the one thing the prototype earned, which is the knowledge of what users actually did with it.
If nobody on your side can review a pull request, this hands you a repository you cannot maintain. The rebuild is worth doing anyway, but plan for who owns it afterwards.
Send me the repository.
Tell me what it does, what it is built on, and what broke last. The reckoning comes back as a document you can read in one sitting, and it is worth having whether or not I do the rebuild.
Start an audit