Loading
← Home
How I work
Six stages, and the riskiest part comes second.
Most project failures are decided in the first two weeks, by something nobody checked. So the order below is deliberate: understand the problem, then attack the single thing most likely to sink it, and only then start building the parts everyone already knows how to build.
- 00
Scope and challenge
Agree what is actually being built, and why
- A written problem statement
- Constraints and non-goals
- 01
Proof of concept
Kill the biggest unknown first
- A working spike against the riskiest assumption
- A go, adjust, or stop recommendation
- 02
Architecture and data model
Decide the shape before writing the bulk
- Architecture and data-flow diagrams
- Schema and interface definitions
- 03
Staged milestone plan
Make progress visible, not reported
- Milestones with demoable outcomes
- Sequence, dependencies and estimates
- 04
Build, test, review
Write it so it survives contact with users
- Tested, reviewed increments
- A demo at each milestone
- 05
Deliver and hand over
Leave it operable without me
- Deployed and configured
- Runbook and architecture docs
- 00
Scope and challenge
Agree what is actually being built, and why
- A written problem statement
- Constraints and non-goals
- 01
Proof of concept
Kill the biggest unknown first
- A working spike against the riskiest assumption
- A go, adjust, or stop recommendation
- 02
Architecture and data model
Decide the shape before writing the bulk
- Architecture and data-flow diagrams
- Schema and interface definitions
- 03
Staged milestone plan
Make progress visible, not reported
- Milestones with demoable outcomes
- Sequence, dependencies and estimates
- 04
Build, test, review
Write it so it survives contact with users
- Tested, reviewed increments
- A demo at each milestone
- 05
Deliver and hand over
Leave it operable without me
- Deployed and configured
- Runbook and architecture docs
Any stage can end with “do not build this”. That is a valid outcome, not a failed project.
- 00
Scope and challenge
Agree what is actually being built, and why
Before any estimate, I want the problem rather than the feature list. That means asking what happens if we do nothing, who the real user is, and which constraints are genuine. If I think the plan is wrong I say so here, in a sentence, while changing it is still free. Quite often this stage removes work rather than adding it.
What you get
- A written problem statement
- Constraints and non-goals
- A fixed-price or staged proposal
Done when: We both describe the problem the same way.
- 01
Proof of concept
Kill the biggest unknown first
Every project has one thing that could sink it: a file format that does not parse, a device that will not stream, a model that is not accurate enough, a latency budget that cannot be met. I build a throwaway spike against that one risk before anything else, because a project that is going to fail should fail in week one for a small fee, not in month four for a large one.
What you get
- A working spike against the riskiest assumption
- A go, adjust, or stop recommendation
Done when: The hardest unknown is now a known.
- 02
Architecture and data model
Decide the shape before writing the bulk
Data flow, module boundaries, interfaces, and the failure modes each one has. I draw it, because a diagram makes a bad boundary obvious in a way that prose hides. The data model gets the most attention: schemas are the hardest thing to change once real data is in them, and most painful rewrites trace back to a decision made here in five careless minutes.
What you get
- Architecture and data-flow diagrams
- Schema and interface definitions
- Named failure modes
Done when: You can see how it fits together without reading code.
- 03
Staged milestone plan
Make progress visible, not reported
The work is split into milestones that each end in something you can open and use, not a percentage in a status update. Each milestone is small enough to demo and independent enough to reorder if your priorities move. You always know what is done, what is next, and what it costs.
What you get
- Milestones with demoable outcomes
- Sequence, dependencies and estimates
Done when: Every milestone has a definition of done you agreed to.
- 04
Build, test, review
Write it so it survives contact with users
Tests go in alongside the feature, not in a cleanup phase that never arrives. Edge cases, error paths and empty states are part of the work rather than a follow-up ticket. Every change goes through review before it lands, including an adversarial pass whose only job is to break what I just wrote. You get a demo at each milestone, and I would rather show you something half-built early than something polished too late to change.
What you get
- Tested, reviewed increments
- A demo at each milestone
- An honest list of what is not done
Done when: It works, including when the user does the wrong thing.
- 05
Deliver and hand over
Leave it operable without me
Deployment, environment configuration, and the documentation someone else needs to run it. Architecture notes, a runbook for the things that break, and a written account of the decisions and their reasons. The measure of a good handover is that your next engineer can make a change in their first week without calling me.
What you get
- Deployed and configured
- Runbook and architecture docs
- Handover walkthrough
Done when: Someone who is not me can operate and extend it.
You can stop at any stage
Each stage ends in something you own: a document, a spike, a diagram, a working increment. If you want to take it in-house or to another engineer after stage 02, you can, and you will have what you need to.
I will tell you not to build it
If the proof of concept says the idea does not work, or the thing you asked for is not the thing you need, you hear it immediately. A small invoice and an honest no beats a large invoice and a slow yes.
No status-report theatre
Progress is a thing you can open and click, at every milestone. If something slipped, I say what slipped and why, rather than moving a bar from 60 to 65 percent.