The mythology of the MVP has produced as many failed startups as it has successful ones. 'Build the simplest version that tests the hypothesis' is good advice that's been wildly misinterpreted. The simplest version that tests the hypothesis is not a landing page. It's not a five-slide deck. It's not a Typeform. It's a working piece of software that delivers enough value to a specific person that they would be genuinely disappointed if it disappeared. Getting to that bar — and no further — is the hardest product decision early-stage founders face. We've worked with enough seed-stage companies to have a clear view of what the winning builds have in common.
The Three MVP Traps
The first trap is over-building. Most first-time founders build for their imagined version of product-market fit, not their current understanding of it. They build admin dashboards before they have users. They build integrations for enterprise clients before they have SMB clients. They build horizontal features for a market segment they haven't validated. The result is months of runway spent on code that will be substantially rearchitected. The second trap is under-building — shipping something so minimal that you can't actually learn from user behavior. A landing page with a waitlist doesn't tell you whether users will return. You need to build enough that users can fully experience the product's core promise. The third trap is the wrong tech stack — choosing technology based on team familiarity rather than product requirements, leading to costly retrofitting at exactly the moment you should be accelerating.
The Stack Decisions That Scale
At the seed stage, your architecture decisions should optimize for two things: speed of iteration and cost of change. You don't know which features will survive first contact with real users. Your data model will change multiple times before you hit your first hundred active users. Your infrastructure needs to be maintainable by a CTO hire who joins at month eight with no prior context on your system. Our recommendation for most B2B SaaS MVPs: Next.js on the frontend, Supabase or PlanetScale as the database layer, and Railway or Render for hosting. Simple CI/CD baked in. No Kubernetes. No microservices. No infrastructure that requires a specialist to maintain. Complexity at the seed stage is a liability, not a signal of quality.
What a Sprint-Based MVP Build Looks Like
We typically scope a seed-stage MVP as a five to eight sprint engagement. Sprints 1-2 focus on the core authentication and primary value-delivery feature — the one thing the product does that no spreadsheet can replicate. Sprints 3-4 build the secondary features that make the primary feature stickier — saved state, basic notifications, the dashboard that shows users their progress. Sprints 5-6 cover the onboarding flow, empty states, and the moment of first value — the specific event that happens in a new user's first session that makes them think 'this was worth signing up for.' Sprints 7-8 add feedback collection, basic analytics, and the first optimization cycle informed by real user behavior. At the end of eight sprints, you have a product you can pitch to Series A investors with real usage data, real retention signals, and a codebase worth inheriting.
The Signals That Tell You PMF Is Near
Sean Ellis's 40% rule remains the most useful PMF heuristic: if at least 40% of your users say they would be 'very disappointed' if they could no longer use your product, you're at or near product-market fit. But long before you run that survey, there are behavioral signals in your sprint data that tell you you're getting warmer. Users are requesting features you were already planning — meaning they understand the product's direction intuitively. Retention is stabilizing — users who return after day 7 also return after day 30. Support requests are shifting from 'how do I do X?' to 'can you add Y?' — the migration from confusion to advocacy. These signals should inform what you sprint on next. A development partner who can read them and adjust the roadmap in real time is delivering something more valuable than code.
Building a seed-stage MVP? Tell us what you're building and we'll tell you which sprints you need first.
Plan My MVP