Assessment into build
A free assessment as the front door, and a phase plan that survives it
A clinical recording product where the mobile app could not depend on a backend that was not finished. I gave the assessment away and made the first phase provably independent.
- Codebase, architecture and experience review before anyone commits
- Stage 1 freeCodebase, architecture and experience review before anyone commits
- Every phase quoted as three numbers rather than one
- Min / real / maxEvery phase quoted as three numbers rather than one
- The recorder ships without the client's backend existing
- Phase 0 independentThe recorder ships without the client's backend existing
The client
A US clinical documentation startup building an ambient recorder for medical visits — audio capture, transcription, then an AI-drafted clinical note — with the intelligence layer being built by the client and the mobile product by us.
The engagement
A free product and technical assessment as stage one, then two phases costed as minimum, realistic and maximum hours, with prepayment per specialist before each phase begins.
The problem
In a product split between two teams, the mobile side is always asked to wait for the intelligence side, and then blamed for the schedule. Add the fact that this recorder must not lose a single clinical visit — through backgrounding, an incoming call or a crash — and the risk is not a feature list, it is reliability that nobody notices until it fails once.
What I did
I made the first phase provably independent by building against a mock interface with an explicit switch to production, so the recorder could be finished, tested and demonstrated whether or not the backend existed. Reliability was scoped as its own module rather than assumed: what happens when the app is backgrounded, when a call arrives, when the process is killed — with no-data-loss as the acceptance criterion rather than as an aspiration. The upload queue was specified to survive a restart, because retry logic that lives only in memory is a promise, not a mechanism. Effort was quoted as three numbers per phase rather than one, and everything the mobile app would not do — transcription, the drafting agent, note editing, consent handling — was written into the proposal as an exclusion, since in a split-team product the exclusions are what prevent the argument.
What was built
A phase-zero mobile recorder built as a standalone product — session start, recording controls, reliability under backgrounding, calls and crashes, offline-first local storage, an upload queue with retry that survives restart, and a mock interface with a switch to production — followed by an integration phase, with transcription, the drafting agent and note editing explicitly out of scope.
On the table at the end
- Free product and technical assessment: findings, risks and recommendations
- Two-phase plan with minimum, realistic and maximum hours per phase
- Modular mobile architecture with a mock-to-production switch
- Explicit out-of-scope list
What it changed
Removed the client's risk of committing before knowing, and removed our risk of building against an unfinished backend — the first phase was scoped to be genuinely independent, so schedule slippage on their side could not stop ours.
How it ran
- 01
Give away the assessment
Codebase, architecture and experience reviewed for free, producing findings and risks — the client sees how we think before paying for anything.
- 02
Make phase one independent
Mock interface with a production switch, so the mobile product cannot be blocked by the other team's schedule.
- 03
Scope reliability as a module
Backgrounding, interruptions and crash recovery treated as deliverable work with no-data-loss as acceptance.
- 04
Make the queue durable
Upload retry that survives process restart, because in-memory retry is a promise rather than a mechanism.
- 05
Write the exclusions
Transcription, drafting, note editing and consent explicitly out of scope — the sentences that prevent the later argument.
Other work
All case studies →- Private capital
Three doors instead of one number
A fund's back-office module needed rebuilding and the budget was not stated. I priced three genuinely different scopes rather than guessing which one they meant.
- Aviation
Twenty days of discovery that priced a year of build
An airport group needed to replace a security-credentialling system under a sovereign compliance regime. Twenty person-days of discovery produced five approved deliverables and an effort envelope the fixed-price contract could stand on.
- Health tech
The estimate that covered a third of what the client thought they were buying
Two documents described two different products and both carried our logo. I stopped the contract, wrote the discrepancy register, and split the release into a fundraising build and a regulated one.
Something similar on your plate?
Thirty minutes, no deck. I will tell you whether it is worth doing at all.