A UK-based founder came to us with a booking app idea and a six-week runway before a planned pilot with early customers. Six weeks is tight for any mobile app. It's only realistic if the scope is cut hard before development starts, not adjusted on the fly once deadlines start slipping.
What actually shipped
We scoped the MVP down to three flows: booking a slot, paying for it, and getting a reminder before it. That's it. No account settings beyond the basics, no in-app messaging, no loyalty program — all reasonable features, all explicitly deferred until after the pilot proved the core booking flow actually worked for real customers.
What we cut, and why it wasn't a compromise
- In-app messaging — deferred in favor of a simple "call or email" fallback, because building real-time chat well takes longer than the entire remaining budget allowed, and a fallback that works is better than a chat feature that half-works.
- Loyalty/rewards — cut entirely for v1. A rewards program only matters once there's a base of repeat customers to reward, and the pilot's whole purpose was finding out whether that base would exist.
- Custom admin dashboard — replaced with a lightweight off-the-shelf tool for the founder to manage bookings manually during the pilot, saving weeks of internal tooling work for a problem that didn't need a custom solution yet.
Every feature we cut wasn't a "maybe later." It was a "not yet, and here's exactly what needs to be true before it's worth building."
What happened after launch
The pilot ran, the core booking flow held up under real usage, and the founder had actual data — not guesses — about which of the deferred features customers actually asked for versus which ones we'd assumed mattered. Two of the three "obvious" next features we'd expected to build turned out not to be what customers wanted first, which would have been an expensive thing to discover after building them instead of before.
KEY TAKEAWAYS
- A six-week MVP timeline only works with scope cut hard upfront — not adjusted once deadlines slip.
- Deferred features should have an explicit condition for when they're worth building, not just "maybe later."
- Shipping a narrow MVP fast often reveals that assumed-important features aren't what customers actually want first.
This space is available for a relevant sponsor or partner. Get in touch to enquire about placement.
Have an MVP idea and a tight runway?
Tell us the timeline and the core problem — we'll tell you honestly what fits inside it and what doesn't.
Start the conversation →