The 5-Day Sprint That Actually Works

Most of my client work ships in five days. Not five weeks, not five sprints — five actual working days. People assume this means cutting corners, but it's the opposite. A tight timeline forces clarity that longer projects never achieve.

Here's the methodology I've refined over the past two years.

Why five days

Parkinson's law is real: work expands to fill the time available. Give a project six weeks and you'll spend four of them in discovery loops, stakeholder alignment, and second-guessing. Give it five days and you have to make decisions. Fast.

The five-day constraint does three things:

• It forces scope ruthlessness. You can't build everything, so you build the thing that matters most.

• It eliminates politics. There's no time for design-by-committee. Someone decides, and we move.

• It creates urgency without panic. Five days is tight but achievable. It focuses the mind without burning people out.

Day 1: Scope and structure

Monday is entirely about defining what done looks like. I write a one-page brief with the client that answers three questions:

• What is the single most important outcome?

• What does the user see and do?

• What's explicitly out of scope?

That last question is the most important. Scope is defined by what you say no to. By end of Monday I have a clear brief, a rough sitemap or flow, and a list of things we're deliberately not doing.

Day 2: Design in the browser

I don't design in Figma. I design in code. Tuesday is about standing up the core layout, typography, and component structure in Next.js. The client sees a real URL by end of day — not a mockup, not a prototype, a real page they can click through on their phone.

This changes the feedback dynamic completely. People give better feedback on real things than on pictures of things. Colour, spacing, hierarchy — it all reads differently in a browser.

Day 3: Build and iterate

Wednesday is the most productive day. The structure exists, the direction is set, and now it's about filling in the detail. Content, interactions, responsive behaviour, data integration. I typically do two feedback rounds on Wednesday — a morning check-in and an afternoon review.

Day 4: Polish and edge cases

Thursday is for the things that separate good from great: loading states, empty states, error handling, animation timing, image optimisation, SEO metadata. This is where craft lives. Most of the work that makes something feel professional happens on day four.

Day 5: Ship

Friday is deployment, documentation, and handover. The site goes to production. I write a brief guide covering how to update content, what the tech stack is, and where to find things. Then we do a final walkthrough together.

When it doesn't work

Not every project fits a five-day sprint. It breaks down when:

• There are more than two decision-makers. Alignment takes too long.

• The project requires complex backend logic or third-party integrations with uncertain APIs.

• Content doesn't exist yet. You can't design around placeholder text and get a real result.

For those cases I'll run a two-week version with the same structure — scope, design, build, polish, ship — just with more breathing room in each phase.

The deeper principle

The five-day sprint works because it aligns incentives. The client gets something real, fast. I get to do focused, deep work without context-switching. And the compressed timeline means decisions are made by the people doing the work, not by a committee three layers removed.

Shipping fast isn't about speed. It's about eliminating everything that isn't the work.