Process
Five stages. Each one ends with a concrete deliverable (a document, a staging URL, a pipeline, a runbook), so you always know where the project stands.
- 01
Days, not weeks
Discovery
Before anything is designed I want to know what the product has to do, who pays for it, and what breaks if it's wrong. For an ERP that's 'what happens when an invoice is corrected'; for a marketplace it's 'who holds the money and when'. Most expensive mistakes are made here, so this is where I ask the awkward questions.
You get
- A one-page brief we both agree on
- The list of things that are deliberately out of scope
- A rough size and cost, with the assumptions written down
- 02
One to two weeks for a new product
Architecture
The data model, the boundaries between services, the security model, and how money moves. I write this down before I write code, because a diagram is cheaper to change than a schema with data in it. You get to see the shape of the thing and push back.
You get
- Data model and ERD
- Security and permissions model: who can see what, and how that's enforced
- Deployment plan: where it runs, how it ships, what it costs to host
- 03
Milestones you approve
Build
Small, reviewable diffs. Tests that run against a real database, not mocks. Written updates at the end of every working day so you never have to ask where things are. You see working software early, on a staging environment from the first milestone. I'd rather hear 'that's not what I meant' in week two than week ten.
You get
- Staging environment from milestone one
- Daily written updates
- Tests, lint, type-check and CI green on every merge
- 04
Planned, not hoped for
Ship
Production deploys through CI, not from a laptop. Store submission for mobile, with the review notes and screenshots done. A runbook that says how to deploy, roll back, read the logs and fix the three most likely things to go wrong, written so someone who isn't me can follow it.
You get
- CI/CD pipeline to your infrastructure
- App Store / Play Store submission
- A runbook and a handover call
- 05
Ongoing, if you want it
Operate
The part that usually gets forgotten: monitoring, backups, dependency updates, the occasional 2am incident. I can stay on retained hours, or hand over cleanly. Everything is in your repos, your accounts, your infrastructure, with nothing that only lives in my head.
You get
- Retained hours, or a clean handover
- Diagnostics you can run yourself
- Your code, your infrastructure, your keys
Principles
Four habits that shape all of it.
Measure before changing
On an existing product I look at what the bundle actually ships, where the requests go and which query is slow before I touch anything. The fix is usually smaller than people expect once you know where to look.
Smallest correct diff
I don't refactor broadly, invent abstractions or touch files outside the ticket. Wide diffs are how you get a regression two screens away.
Say what you didn't do
Every handover says what changed and what I deliberately left alone. Anything I noticed out of scope goes in a note, not in the diff.
Write it down
Architecture, decisions, runbooks. If it's only in a conversation it doesn't exist.
Have a product to build, or one that needs to work better?
Two or three sentences is enough. I'll come back with what I'd do, how long it takes and what it costs.