How We Ship Working MVPs in 4 Weeks (And Why Most Can't)

When we tell people we ship working MVPs in 4 weeks, the most common reaction is scepticism. "That's a prototype, not a real product." "You're cutting corners." "That's not possible for anything meaningful."

We've now shipped 15+ MVPs on this timeline. Some have gone on to raise funding. Some became full products with tens of thousands of users. None were prototypes — they were real, deployed applications that real users used. Here's exactly how.

Week 0: The Scope Sprint (often the hardest part)

Before the 4-week clock starts, we do a scope sprint. This is where most teams fail. They arrive with a vision — which is good — but also with a list of 47 features — which kills the timeline. The scope sprint is a disciplined process of identifying the single core hypothesis the MVP needs to test, and the minimum feature set required to test it. Everything else goes on a "v2 wishlist." This session is often uncomfortable. But without it, you can't ship in 4 weeks. You also probably can't ship in 40 weeks, because you haven't made decisions.

Week 1: Architecture + Design

Day 1–2: Technical architecture and stack decisions. We pick boring, proven technology over interesting new technology. The goal is delivery speed and maintainability, not showcasing our knowledge of bleeding-edge frameworks. Day 3–5: UX design for core flows only. We use Figma, we work fast, and we prioritise clarity over polish. The design artifacts are there to communicate intent, not win awards.

Week 2–3: Build

We build feature by feature, not layer by layer. We don't build the full backend before the frontend. We build the first feature end-to-end, then the second, then the third. This means something is always demoable. Daily standups are 10 minutes. No sprint planning meetings. No retrospectives. Just shipping.

Week 4: Integration + Launch prep

Integration with any third-party services. Performance testing. Basic analytics setup. Deployment to production. User acceptance with the client team. On Friday of week 4, we hand over a deployed, working application with documentation.

Why most teams can't do this

Most teams can't ship in 4 weeks because: (1) They haven't made decisions — they want to "keep options open." (2) They have too many stakeholders with too many opinions. (3) They pick unfamiliar technology because it's on trend. (4) They build infrastructure for scale they don't have yet. (5) They want it to be perfect before users see it. None of these are the right posture for an MVP. An MVP is a question disguised as a product. You're asking: "Is this something people actually want?" Get it in front of users. You'll learn more in one week of real usage than in six months of planning.