Process
How I actually run a project.
No "design sprint week", no Notion-template-as-deliverable. Three steps, clear deliverables, and a timeline I'll commit to once I understand the brief.
01
Discover
A call (or two) and a written scope. The point of this step is to stop you spending money on the wrong thing.
What happens
We talk for thirty minutes. If it's clearly a fit, we book a longer follow-up where I ask the awkward questions: what does success look like, what have you already tried, what's the constraint nobody's said out loud yet. Then I go away and write it up.
Deliverables
- A written scope: what we're building, what we're not, and the order things happen in.
- A fixed quote (or a clearly-bounded estimate where genuine unknowns warrant it).
- A first-week plan so you know where my time is going on day one.
Typical timeline
One to two weeks from first call to signed scope. Less for small projects, more if there are stakeholders to align.
02
Build
Small, reviewable chunks of work. You see progress every few days, not in fortnightly slabs.
What happens
I work in two-week cycles with a short Loom update at the end of each. You get a staging environment from day one — every change goes there first, so you can actually click around. No surprises at the end of the month.
Communication is on whatever you already use: Slack, email, Linear, a shared issue tracker. I'll match your team's working pattern rather than insisting on mine.
Deliverables
- A staging URL or store, kept up to date.
- End-of-cycle Loom walkthroughs (so you can share them with stakeholders).
- A working changelog you can read without opening the repo.
Typical timeline
Most builds are between four and twelve weeks. Anything longer than that, we'll break into phases with a check-in at each phase boundary.
03
Hand-off
A proper handover so the project doesn't quietly become my permanent responsibility.
What happens
Code is shipped, docs are written, accounts are transferred. We do a live walkthrough call with whoever's going to be running the thing. After that there's a short maintenance window where I'm on hand for the inevitable "what about…" questions.
Deliverables
- Plain-English docs covering the bits a non-developer needs to operate.
- Developer notes for the bits future-you might need to extend.
- Loom recordings for any process that's easier to watch than read.
- A clean repo handover (or a starting-point if you didn't have one).
Typical timeline
One to two weeks of handover, then a 30-day post-launch window where small fixes are included. Anything bigger after that is a new conversation.
Sound like the way you want to work?
A few sentences about the project is enough to get the conversation started. It's how every one of them does.