Our method
Preserve what works. Fix what matters. Launch with evidence.
The same ten steps on every engagement, in the same order. The order is the point: reproduce before diagnosing, diagnose before repairing, verify before claiming anything is fixed.
- 01
Reproduce
Make the problem happen on demand. A fault that cannot be reproduced cannot be verified as fixed.
- 02
Baseline
Freeze and record the starting state before anything changes, so the work can be compared against it later.
- 03
Diagnose
Find the actual cause with evidence. Symptoms get captured; causes get named.
- 04
Prioritize
Rank findings by real business risk, not by how interesting they are to fix.
- 05
Preserve
Identify what already works and protect it. Most of a stalled codebase is usually fine.
- 06
Scope
Agree the smallest responsible piece of work with explicit acceptance criteria and exclusions.
- 07
Repair
Implement only the agreed work, in small reviewable changes.
- 08
Verify
Prove the repair with tests and evidence — in the environment that actually matters, not only on a laptop.
- 09
Document
Record what was wrong, what changed, what was deliberately left alone, and what remains unverified.
- 10
Handoff
Leave the work maintainable by someone else, including the next developer who is not me.
Why this order
Most of the value is in the first four steps
The temptation with broken software is to start fixing. It feels productive and it is usually wrong, because a fix applied to a symptom moves the problem rather than removing it.
Reproducing first means we can prove the repair later. Freezing a baseline means there is something to compare against. Diagnosing before prioritising means the ranking reflects causes rather than noise.
By the time we reach Repair, the hard thinking has been done and the work is comparatively mechanical — which is exactly how it should feel.
Verify means verify where it runs
A passing local test suite proves that the software works on the machine that built it. Hosting platforms apply their own defaults for permissions, configuration, and environment, and those differences are invisible locally.
We verify in the deployed environment. In our own demonstration, one entire class of permission defect existed only once the application was hosted — and every local check was green throughout.
Document means document honestly
A delivery report records what changed, what was deliberately preserved, and what could not be verified. That last section is the one that matters most, and it is the one most often left out.
Working with us
What you can rely on
No automatic rewrite recommendation
A rewrite gets recommended only when evidence supports it. Preserving working code is the default.
No free disguised code audit
A free conversation identifies the problem. Investigating the cause is paid work, and it is priced up front.
No silent scope expansion
Scope changes are raised and agreed, never absorbed quietly and billed later.
AI output is not proof
AI accelerates delivery. It does not replace verification, and it is never the accountable party.
No production changes without authorization
Access is not permission. Production work happens only when explicitly agreed.
Candid reporting
What could not be verified gets stated plainly, including when that is inconvenient.
See the method applied end to end
The ClientFlow case study walks through all ten steps on a real codebase — including the finding we did not expect to have.