Process
A repeatable, boring, effective way to ship software.
There are five phases. Each one ends with a working artefact: a written plan, a running prototype, a deployed product, a clean handover. If a phase does not end with something you can hold, I have not done it.
- 01 1 week
Discover
I sit down with you, or jump on a video call, and pry the problem apart. What does success look like, what can be cut, what is non-negotiable. Output is a written plan.
- 02 1 to 2 weeks
Sketch
Fast loops on paper, in Figma, in throwaway prototypes. I would rather throw away the wrong idea cheaply than ship it expensively.
- 03 3 to 8 weeks
Build
You see working software end-to-end within ten days. I push to a staging URL every working day. No surprises on demo day, because demo day is every Friday.
- 04 1 week
Ship
Submit, certify, deploy. I handle App Store review, DNS, secrets, the lot. You get a calm release, not a midnight panic.
- 05 Ongoing
Support
Ongoing retainer, or a clean handover with documentation that does not lie to your future engineers. Your team should never feel locked in.
A typical week, in practice
Most engagements settle into a rhythm in the first two weeks. Here is what a typical week looks like once I am in the build phase.
Monday
Short async update by 11am: what I am shipping this week, what I got wrong last week, where I would like a decision from you. You do not need to attend a meeting. You do need to read three paragraphs.
Tuesday to Thursday
Heads-down build. Pull requests merged daily into a staging environment you can open from your phone. When something is hard I write it down before I write it in code, so you can see the reasoning before the implementation.
Friday
Demo call. Thirty minutes, screen shared, working software. You poke at it. You break it. I write down what hurt. That becomes Monday's plan, and then we do it again.
Communication
Slack (or whatever you use) for fast-moving things. Email for decisions you want to find again in six months. A shared Notion, Linear, or Google Docs space. I use whatever you use, with no fuss.
There is no project manager whose job is to remind me to update Asana. I am the one writing the code. I am also the one writing the updates. That tends to be the part clients are most relieved by, in retrospect.
What I expect from you
- One decision-maker who can say yes and no.
- Honest feedback by Friday afternoon, even when it is "we don't love it".
- Access to the right people internally when I need to understand a part of the business.
- Permission to disagree, and a willingness to disagree back.
Have a project in mind?
Tell me what you're trying to ship. I respond personally within one working day.