How we cut an MVP from 12 weeks to 5
A week-by-week breakdown of a booking platform build, and where the time really went.
When a sailing school asked us for a booking platform, our first estimate was twelve weeks. We launched the first version in five. AI tools helped, but they weren’t the main reason. Most of the time came from deciding what not to build.
Where the 12 weeks came from
The original wish list had 34 features: memberships, gift vouchers, a referral programme, instructor payroll, a weather integration, a parent portal for kids’ camps and more. All reasonable. Most not needed on day one.
Week 1: cut the scope in half
We spent two days on the jetty and one day reading six months of enquiry emails. Almost every question was one of three: Is there space?, What do I need to bring? and How do I pay? The MVP became: course pages that answer those questions, live availability, online payment, and a staff view that prevents double-booking. Eleven features instead of 34.
Week 2: design only the hard parts
We designed the booking flow and the staff timeline in detail and tested both with real students and instructors. Everything else used components from our starter kit.
Weeks 3–4: build with AI where it fits
- AI tools scaffolded the admin screens and wrote the migration from three spreadsheets: about four days saved.
- The scheduling rules that prevent conflicts were written and tested by hand, because getting them wrong means two crews and one boat.
- We demoed on a live staging link every Friday.
Week 5: launch quietly
We launched to the school’s mailing list first, not the public. Two small bugs, both fixed the same day. Public launch the following Monday.
| Phase | Original plan | Actual |
|---|---|---|
| Discovery | 2 weeks | 1 week |
| Design | 3 weeks | 1 week |
| Build | 6 weeks | 2 weeks |
| Launch & fixes | 1 week | 1 week |
AI saved us days. Scope saved us weeks.
Of the 23 features we cut, nine were built over the following six months. Fourteen were never requested again.