Process
Two weeks is a method, not a promise.
It works because the shape of the project is fixed before it starts: what's in scope, when reviews happen, and what each one is for. Here's the whole thing.
- 01Day 1
Kickoff
A 45-minute call. Who buys, why they hesitate, what the site must make happen. I leave with your assets and a written brief you sign off on that day.
- 02Days 2–3
Structure
Page map and messaging skeleton: what each section is responsible for, in what order, before any visual design. This is where most of the thinking happens and where changes are cheapest.
- 03Days 4–10
Build
I design directly in code — no static mockups to approve, then rebuild. You get a live preview URL from day four and watch it come together. First review at the end of week one.
- 04Days 11–14
Launch
Second review, polish, performance pass, analytics wired to your real conversion events. Then it ships to your domain, in your GitHub org, with a README.
Day by day
Roughly two hours of your time across the whole project, most of it in the first three days.
- 01
Before kickoff
Your logo and any brand assets. Links to three sites you like and one you don't. Access to your current analytics, if any.
- 02
Kickoff call
45 minutes. Who buys, why they hesitate, what the site has to make happen. You'll get a written brief the same day to sign off.
- 03
Review one
End of week one. The homepage is built and live on a preview URL. You react to real pages, not mockups. Feedback within two working days keeps us on schedule.
- 04
Review two
Day 11 or 12. Everything built. This is polish and copy corrections, not restructuring — that happened at review one.
- 05
Launch
Domain pointed, analytics verified, a short handoff call if you want one. README in the repo. You're done.
Ground rules
Four things that keep it to two weeks.
- 01
Feedback goes in one place, batched, not trickled across Slack, email, and calls.
- 02
Structural changes happen at review one. After that, we polish what exists.
- 03
If feedback takes more than two working days, the launch date moves by the same amount. No penalty, just physics.
- 04
I say no to things during the project. It's how the timeline stays real.
On the four steps
01 — Kickoff Day 1
A 45-minute call. Who buys, why they hesitate, what the site must make happen. I leave with your assets and a written brief you sign off on that day.
02 — Structure Days 2–3
Page map and messaging skeleton: what each section is responsible for, in what order, before any visual design. This is where most of the thinking happens and where changes are cheapest.
03 — Build Days 4–10
I design directly in code — no static mockups to approve, then rebuild. You get a live preview URL from day four and watch it come together. First review at the end of week one.
04 — Launch Days 11–14
Second review, polish, performance pass, analytics wired to your real conversion events. Then it ships to your domain, in your GitHub org, with a README.
Next step
Tell me what you’re building. I’ll tell you what it needs.
A short intro call, no deck, no pitch. If I’m not the right fit I’ll say so and point you somewhere better.