Most first releases fail in the same way. The scope grows every week, the launch date slips, and by the time the product reaches real users the budget is gone. Over the last twelve launches we settled on a simple rhythm that avoids this: eight weeks, four sprints, one clear goal.
Why eight weeks
Eight weeks is long enough to build something real and short enough that nobody loses focus. It forces the hard conversation early: what does this product need to do on day one, and what can wait until people are actually using it?
It also gives clients a date they can plan around. Marketing, hiring and investor updates all get easier when launch day is fixed and visible from the start.
If a feature can wait until after launch, it waits. The first release has one job: prove the core loop works for real users.
Week 1: scope that fits
The first week is all about deciding what not to build. We map the core user journey, list every feature anyone has mentioned, and then sort each one into launch, later or never.
- One primary user and one core journey, written down in a single page
- Every screen sketched before any code is written
- A fixed launch date agreed with the client in week one
Rule of thumb
If a feature needs more than one sprint to explain, it belongs in version two.
Weeks 2 to 7: build in sprints
Weeks two to seven run as three two-week sprints. Each one ends with a live demo on a staging link, so the client sees working software every fortnight instead of status reports.
QA is part of every sprint, not a phase at the end. Bugs found in week three cost minutes to fix; the same bugs found in week eight cost the launch date.
Week 8: the launch checklist
The final week is for hardening, not new features. We run the same checklist on every project, and nothing ships until every line is ticked.
const releaseChecklist = [
"Core flow tested on real devices",
"Error tracking and alerts live",
"Backups verified with a restore",
"Rollback plan written down",
];What we cut, and why
Admin dashboards, advanced settings and most integrations usually wait for version two. None of them help a first user get value, and all of them are easier to design once real usage data exists.
The result is a smaller first release that works properly. From there, every new feature is a decision based on what users actually do, not what we guessed in a workshop.
- MVP
- Product strategy
- Delivery
