The MVP Philosophy
Most first-time founders build too much. They imagine their future product at scale and try to build toward that vision immediately. They add features customers might want someday. They perfect details that don't matter yet. Months pass. Money runs out. They never validate whether anyone wants the core product.
The MVP approach inverts this. Build the minimum product that lets you learn whether your core hypothesis is correct. Ship quickly. Get real usage data. Let customer behavior guide what to build next. This isn't about building a bad product. It's about building the right product efficiently.
What MVP Actually Means
Minimum Viable Product is the smallest set of features that delivers the core value proposition to early adopters. These are customers willing to tolerate rough edges in exchange for solving a real problem. The MVP must work well enough to demonstrate value, but no more. The key word is viable. An MVP that doesn't actually solve the problem teaches you nothing. But viability doesn't require perfection. It requires solving the core problem well enough that customers will pay and use it regularly.
The Learning Objective
Every MVP has a learning objective. What do you need to validate? Usually it's some combination of: Does this problem matter enough that people will pay? Can we deliver the solution effectively? Will customers actually use what we build? Can we reach customers efficiently? Define your learning objective before building. It determines what features are essential. If you need to validate willingness to pay, you need functioning payments. If you need to validate usage patterns, you need good analytics. If you need to validate solution effectiveness, you need the core workflow working well.
The 3-Month Rule
If your MVP takes longer than three months to build, you're building too much. This timeline forces prioritization. You can't build everything in three months. You must choose what matters most. This constraint is a feature, not a bug. Three months gets you to market fast enough to preserve momentum and capital. It lets you start learning from real customers while you still have runway. It prevents over-engineering. Some of the most successful SaaS products launched with features you could build in weeks.
Software build: brief to estimate
A brief is ready for estimation when the user problem, constraints, exclusions, and acceptance checks are explicit.
Illustrative framework · Graphic by Nick JensenRead the diagram as text
Flowchart from a software build brief through user problem, constraints, exclusions, and acceptance checks to an estimate-ready scope. A brief is ready for estimation when the user problem, constraints, exclusions, and acceptance checks are explicit.
Identifying Core Features
The Value Proposition Test
Start with your core value proposition. What's the main reason customers will pay? That capability must work in your MVP. Everything else is negotiable. A project management tool must let users create and track tasks. A CRM must capture and organize customer information. An analytics platform must collect and display data. Define the minimum version of this core capability. If it's task management, you need to create tasks, mark them complete, and see what's outstanding. You don't need subtasks, dependencies, custom fields, or integrations. Those can wait. Build the essence of the value proposition first.
The Must-Have Infrastructure
Certain capabilities are required regardless of your specific product. User authentication so people can sign up and log in. Basic user management so you can see who's using your product. Payment processing if you're charging money. These are table stakes for SaaS. Use existing solutions for this infrastructure. Auth0 or Clerk for authentication. Stripe for payments. Don't build these from scratch. They're necessary but not differentiating. Every hour spent on authentication is an hour not spent on your core product.
The Feature Matrix
List every feature you're considering. Score each on two dimensions: importance to customers and difficulty to build. Plot them on a 2x2 matrix. Your MVP includes only high-importance features, prioritizing easy ones when possible. High importance, low difficulty features are obvious wins. High importance, high difficulty features may need creative simplification. Low importance features don't belong in your MVP regardless of difficulty. This exercise makes prioritization objective rather than political.
The Manual Override
Some features can be handled manually in an MVP. Customer onboarding could be a scheduled call instead of an automated flow. Report generation could be you running queries and sending results. Integration with another tool could be you manually syncing data. This approach has limits (you won't scale to hundreds of customers doing manual work), but it's perfect for MVP validation. If customers value the outcome, you can automate later. If they don't, you saved time not building automation for something that didn't matter.
Technical Architecture
The Boring Stack
Use proven, well-documented technologies. This is not the time to learn a new framework or experiment with cutting-edge tools. Pick a stack you know or that has excellent learning resources. The goal is shipping product, not advancing technical knowledge. Modern SaaS stacks typically involve: React/Next.js for frontend, Node.js or Python for backend, PostgreSQL for database, and hosting on Vercel, Railway, or AWS. This stack is well-supported, scales when needed, and has solutions for common problems already documented.
Monolith First
Start with a monolithic application. Frontend and backend in one codebase, deployed together. One database. Simple architecture. You don't have the complexity that justifies microservices yet. You don't have the usage that requires distributed systems. Monoliths are faster to develop and easier to reason about. You can change the entire system in one commit. Debugging is straightforward. Deployment is simple. Extract services later if and when you have problems that justify the complexity.
Buy, Don't Build
Use managed services and third-party APIs aggressively. Authentication: Clerk or Auth0. Payments: Stripe. Email: SendGrid or Postmark. Analytics: PostHog or Mixpanel. Error tracking: Sentry. Each of these would take weeks to build properly. Pay the monthly fee. The cost savings from not building these yourself far exceeds the subscription costs. Plus you get features and reliability you wouldn't achieve quickly building custom solutions. Save your engineering effort for differentiated features.
Observability from Day One
Instrument your application from the start. Track user actions, errors, and performance. You need to understand how customers use your product to know what to build next. Good analytics inform every product decision. Track the full funnel: sign-ups, activation (first real use), retention, and revenue. Identify where users drop off. Measure feature adoption. Monitor error rates. This data becomes your guide for what to fix and what to build next.
Go-to-Market Strategy
Early Customer Acquisition
Your first ten customers should come from manual outreach. You need to understand your customers deeply at this stage. Automated marketing comes later. Start with people you know, industry connections, online communities where your target customers gather. These early users should expect imperfection. You're explicitly asking them to try something new and provide feedback. Many will say yes, especially if you offer preferential pricing or early access benefits. The goal is learning, not revenue.
The Founder-Led Sales Phase
Founders should handle early sales personally. You learn what resonates in pitches. You understand customer objections. You see which features matter and which don't. This knowledge is invaluable for product development and eventual sales hiring. Document everything during this phase. Record sales calls (with permission). Note common questions. Track what closes deals. Build a playbook for when you eventually hire sales people. Your early sales experience becomes your sales training material.
Pricing Your MVP
Charge money from the start. Free products don't validate willingness to pay. You need that signal. Price based on value delivered, not costs incurred. Look at comparable products. Consider what budget authority your target customer has. It's easier to lower prices than raise them. Start slightly higher than you think is reasonable. Some customers will balk. That's useful data. Some will pay without hesitation. That tells you there's room to go higher.
Content and Distribution
Create content that demonstrates expertise in your domain. Blog posts, case studies, how-to guides that solve problems adjacent to what your product solves. This builds credibility and attracts organic traffic. Distribute this content where your audience already spends time. Industry forums, subreddits, Twitter/X, LinkedIn, niche Slack communities. Don't spam. Provide genuine value. Mention your product when relevant. Build relationships before pitching.
Customer Success in MVP Phase
Stay extremely close to early customers. Schedule regular check-ins. Monitor their usage. Respond to support requests within hours. These customers are taking a bet on you. They deserve exceptional attention. Their success is your success. If they achieve their goals using your product, they'll stay customers, refer others, and provide testimonials. If they churn, understand exactly why. Early churn is expected but each churn should teach you something valuable.
Measuring Product-Market Fit
The Leading Indicators
Product-market fit is the point where your product satisfies strong market demand. Before that point, growth is hard and expensive. After it, growth feels easier. Measuring PMF requires tracking specific metrics that indicate you're moving in the right direction. Retention is the strongest signal. Are customers using your product regularly over time? Monthly or weekly active user rates matter more than total sign-ups. Good retention means you're solving a real problem well enough that people keep coming back.
The 40% Rule
Ask customers how they'd feel if they could no longer use your product. If 40% or more say they'd be very disappointed, you're approaching product-market fit. This metric, popularized by Rahul Vohra, indicates strong product value. Below 40% means you need to improve the core product. Focus on the segment that would be disappointed and understand what they value. Build more of that. Iterate until more users find the product indispensable.
Organic Growth Signals
Products with PMF grow organically. Customers refer others. Word spreads. You see sign-ups from channels you didn't directly activate. This viral coefficient indicates strong product value and natural advocacy. Track where new customers come from. High referral rates suggest satisfied customers. Organic search traffic indicates brand awareness. Direct traffic shows people remember and return to your product. These signals emerge naturally when you've built something people want.
Usage Intensity
How deeply do customers engage? Daily active users versus monthly active users shows engagement depth. Time spent in product indicates value creation. Feature adoption rates show whether you're building the right things. High usage intensity means customers integrate your product into their workflows. It becomes habitual rather than occasional. This stickiness protects against churn and increases customer lifetime value.
Customer Feedback Quality
Pay attention to the type of feedback you receive. Pre-PMF, customers say your product is interesting but request fundamental changes. Post-PMF, they love the core product and request extensions and enhancements. This shift indicates you've nailed the core value proposition. Customers want more of what you already do, not different things entirely. This is the signal to accelerate growth rather than pivot.
Iterating Toward Scale
The Post-MVP Roadmap
Once you've validated core hypotheses, systematic improvement begins. Fix the most critical usability issues. Build the highest-value features for retention. Remove friction from onboarding. Each iteration should increase a key metric: activation rate, retention rate, expansion revenue. Use data to prioritize. Which features do retained customers use most? What do churned customers cite as missing? Where do new users drop off? Build based on evidence, not opinions. Your roadmap should reflect what customers demonstrate they value through behavior.
Scaling the Team
Early hires are critical. First engineering hire should ship features independently. First sales hire should close deals with minimal support. First customer success hire should handle escalations and renewals. Each early hire must be effective without extensive management. Hire slowly and carefully. One great hire is worth more than three mediocre ones. Look for people who've built similar products, sold to similar customers, or operated in similar contexts. Experience with your stage and domain is more valuable than general experience.
Technical Debt Management
Your MVP accumulated technical debt. That's expected and acceptable. Now selectively pay it down. Focus on debt that prevents you from moving fast or causes frequent production issues. Ignore debt that doesn't affect velocity or reliability. Allocate 20-30% of engineering time to technical improvements. This prevents debt from compounding while keeping focus on feature development. Perfect code isn't the goal. Sustainable velocity is.
The Growth Engine
With product-market fit established, focus shifts to efficient customer acquisition. Test marketing channels systematically. Measure customer acquisition cost and lifetime value. Find channels where you can profitably acquire customers at scale. This is where many products succeed or fail. Great products with poor distribution lose to good products with great distribution. Invest in growth as much as product. Track what works. Double down on effective channels. Cut underperforming ones quickly.
The Journey Ahead
Building a successful SaaS business is a marathon, not a sprint. The MVP is just the beginning. You'll iterate on product, refine positioning, optimize operations, and scale the team. Each phase brings new challenges. But everything starts with shipping that first version. Stop planning and start building. Get to market. Learn from real customers. Iterate based on data. The best way to build a great product is to ship a good one and make it better every week. Your MVP is waiting. Start building today.
Ship one complete vertical slice
Use a booking as the smallest useful product
Consider a fictional scheduling product. Its first useful outcome is that a person selects an available slot and receives a durable booking or a clear conflict. Calendar synchronization and reminders may matter later, but neither substitutes for making that path correct. The vertical slice includes the visible interface, authorization, validation, persistence, and feedback. Calling only the front end an MVP hides the business rules in a future task and leaves the team unable to test the actual outcome.
One useful slice through the stack
A useful booking slice connects user action to authorization, atomic reservation, durable identity, and visible conflict or confirmation.
Illustrative framework · Graphic by Nick JensenRead the diagram as text
Flow from user selects an available slot, then authenticate and authorize, then validate the request, then atomically reserve the slot, then return a durable booking id, then show confirmation or conflict, then exercise failure and retry. A useful booking slice connects user action to authorization, atomic reservation, durable identity, and visible conflict or confirmation.
Define the invariant at storage
Two people can request the same slot concurrently. A disabled button cannot protect that boundary. The reservation needs an atomic storage rule that allows one successful booking and returns a recoverable conflict to the other request. A retry of the same accepted attempt should not create another reservation. The first figure traces this complete path. In the editorial fixture, a small in-memory example demonstrates identity and conflict semantics; it deliberately does not prove database concurrency. That requires an integration test against the actual persistence rule.
The release scope map
Keep the complete booking outcome in the release; defer convenience and explicitly exclude unrelated product scope.
Illustrative framework · Graphic by Nick JensenRead the diagram as text
Must ship / one complete path: Choose slot, reserve atomically, show confirmation or conflict.; Later / optional convenience: Reminders, recurring appointments, calendar synchronization.; Excluded / different product: Marketplace matching and payroll. Reopen scope before adding them. Keep the complete booking outcome in the release; defer convenience and explicitly exclude unrelated product scope.
| Synthetic request | Expected result |
|---|---|
| New attempt, available slot | One durable booking ID and visible confirmation. |
| Same attempt and same payload | Return the original outcome without another reservation. |
| Different attempt, occupied slot | Recoverable conflict; no second booking. |
| Existing attempt with changed slot | Reject identity reuse; do not silently reinterpret the request. |
| Notification transport unavailable | Keep the booking durable and delivery pending, with an operational owner. |
Draw the release boundary
The second figure separates the required booking path from optional convenience and unrelated product scope. Removing reminders is a reasonable scope choice if the user still receives a clear on-screen result. Removing conflict handling is not: it would invalidate the core outcome. A useful failure rehearsal submits an occupied slot, retries a successful attempt, and simulates a notification outage. Booking state should remain understandable in each case. Name which result is authoritative before deciding how the interface phrases its confirmation.
Expand only after the slice teaches you something
The tradeoff is deliberate incompleteness. A small slice will not satisfy every customer workflow, so document its exclusions and avoid promising a broad launch. Observe actual use before adding convenience features, and reopen the scope when the underlying outcome changes. Begin with one acceptance table covering success, conflict, invalid input, and retry. The scope article explains how to make that table estimate-ready; the duplicate-safe workflow article covers the retry identity that spans the UI and server.