Twenty-day discovery
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.
- Discovery that priced a multi-thousand-hour build
- 20 person-daysDiscovery that priced a multi-thousand-hour build
- Deliverables approved by the client
- 5 of 5Deliverables approved by the client
- Effort quoted per role as a min–max envelope
- Range, not a numberEffort quoted per role as a min–max envelope
The client
An airport group in the Asia-Pacific region operating several regional airports, replacing a legacy aviation security credentialling system under national critical-infrastructure obligations and a government-assessed cloud security regime.
The engagement
A one-month discovery of twenty person-days, paid half on signature and half on delivery, producing five deliverables and the effort envelope for a fixed-price build.
The problem
Replacing an aviation security credentialling system means integrating with a federal identity-checking service, a document verification service, physical access control at four sites and a payment channel, under critical-infrastructure obligations and a government-assessed cloud regime, with real regulatory consequences for getting it wrong. Nobody can price that responsibly from a requirements document, and a fixed-price contract signed without discovery is a dispute with a start date.
What I did
I made discovery the product. Twenty person-days, a fixed fee split half on signature and half on delivery, and five deliverables sequenced so that each one was approved before the next depended on it — vision and scope, then target architecture, then the work breakdown, then non-functional requirements, then the release split. The architecture was designed inside the sovereign compliance regime from the first diagram rather than retrofitted, with data classes and trust zones stated explicitly and recovery objectives derived from criticality tiers rather than asserted uniformly. The effort estimate came out per role as a range rather than a single number, and the deferred list was written down as carefully as the committed one, so the fixed-price release the client eventually signed had a defensible boundary on both sides. What sat outside our control — the federal service, the access-control head end, the payment channel — was named as outside our service commitments before anyone signed.
What was built
Five sequenced deliverables — vision and scope with measurable business outcomes, a target architecture inside the sovereign cloud regime, a work breakdown across seventeen workstreams, non-functional requirements tiered by criticality with recovery objectives per tier, and an explicit split between the first release and everything deferred — each approved by the client before the next depended on it.
On the table at the end
- Vision and scope: six business outcomes, ten scope domains, seven measures
- Target architecture under the assessed-cloud regime, five trust zones, hardened baseline
- Work breakdown across seventeen workstreams
- Non-functional requirements: thirteen critical flows, three availability tiers, five data classes
- First-release versus deferred split across twenty-three features
- Development effort estimate by role, as a range
What it changed
Converted an unpriceable regulated replacement into a fixed-price build with a defensible effort envelope — and did it for twenty person-days, so the client's exposure while the scope was still unknown was a month rather than a quarter.
How it ran
- 01
Sell the discovery as its own deliverable
Twenty person-days, fixed fee, half on signature and half on acceptance — so the client's exposure while scope was unknown stayed a month.
- 02
Sequence the deliverables
Vision and scope, architecture, work breakdown, non-functional requirements, release split — each approved before the next leaned on it.
- 03
Design inside the compliance regime
Sovereign cloud, trust zones, immutable storage and a hardened baseline from the first diagram, not as a later hardening exercise.
- 04
Tier the non-functional requirements
Thirteen critical flows, availability tiers and recovery objectives per tier, five data classes — so the build could be costed against real obligations.
- 05
Quote a range and name the deferrals
Effort per role as a min–max envelope, first release versus deferred stated explicitly, and third-party dependencies excluded from our service commitments in writing.
Other work
All case studies →- 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.
- Software services
Nineteen estimates, one register, five minutes to an answer
Four years of pricing lived in spreadsheets nobody could open. I rebuilt the commercial history into one register — what was estimated, what it sold for, what happened next — and found that half the formulas were already dead.
- Insurance
Sequencing the data foundation before anyone bought an AI agent
A financial group wanted AI scoring across five affiliates. I proposed one affiliate, eighteen weeks, and a data readiness report before a single model — because the alternative is an agent trained on data nobody has reconciled.
Something similar on your plate?
Thirty minutes, no deck. I will tell you whether it is worth doing at all.