"Concept to code" is our promise, so people fairly ask what it looks like in practice. Here's a typical MVP engagement, week by week. Every project bends this a little, but the shape holds for most of the products we build.
Day one: the one-page plan
We start with a half-day workshop with the people who will own the product. By the end of it we've agreed who it's for, the one job it has to do well, and what we're deliberately leaving out. That last list is the most valuable thing we write all project.
The output is a single page: goals, users, constraints, risks and a rough plan. If it doesn't fit on one page, the scope is too big for seven weeks, and we say so on day one rather than in week five.
We also agree who from the client's side joins the Friday demos and who can make a final call. Most delays in a seven-week project aren't technical; they're a decision waiting for someone who isn't in the room.
Weeks one and two: prototype
Designers and engineers start together. Flows get sketched on paper, then built as a clickable prototype with real content from the client. By the end of week two, five or six real users have tried it, and we've changed it based on what they did rather than what they said.
- Flows and wireframes in the first three days
- A clickable prototype by the end of week one
- Usability sessions with real users in week two
- A short list of what changes before production
Weeks three to six: production, demoed every Friday
This is where most of the work happens. We build in thin vertical slices, so each week adds something a person can actually use rather than a layer nobody can see. Every Friday the client gets a demo on a real URL and a two-line update: what shipped, and what's next.
Deadlines move. The Friday demo does not.
The demo is the heartbeat of the project. It forces us to finish things, it gives the client a cheap chance to change direction every week, and it means nobody is surprised at the end.
Behind the demos, the unglamorous work happens on schedule: CI/CD from the first week, infrastructure as code, error tracking and accessibility checks on every pull request. The Friday note looks like this:
Week 4 · Friday demoShipped: invite flow, team roles, email templatesChanged: roles cut from 5 to 3 after testingNext: billing, usage limitsRisk: payment provider review takes 5 daysWeek seven: ship
Launch week is deliberately quiet. Features freeze at the start of the week; the rest is testing on real devices, performance passes, analytics and a staged rollout. We write the handover docs as we go, so week seven is for checking them, not starting them.
After launch the client gets thirty days of support from the same crew. The code, the infrastructure and the design files have been theirs since day one.
What makes seven weeks possible
Speed comes from removing waiting, not from working longer days. A few habits do most of the work:
- One crew from concept to launch, so nothing is lost in a handover
- Decisions made in the Friday demo, not in a meeting the week after
- A boring, proven stack, so the time goes into the product
- A scope that's allowed to shrink, but never to grow without a trade
The short version
One page on day one, a tested prototype in two weeks, a demo every Friday and a quiet launch in week seven. It isn't magic. It's a small crew, a fixed rhythm and a client who sees the real thing every week.