A step-by-step playbook for developing an MVP — from one-sentence hypothesis to a build-ready spec your engineers can quote in 24 hours.
"How do I develop an MVP?" is a question that hides a more important question: what work is supposed to happen before I write any code? Most founders skip the answer and start with engineering. The cost of that shortcut is roughly 30–50% of the eventual build budget, plus a few months of avoidable rework.
This is the playbook I run with clients. Five steps, in order. None of them require an engineer until step six.
Step 1: Write the one-sentence hypothesis
Every MVP exists to test exactly one thing. If you can't fit it in one sentence, you don't have an MVP — you have a feature list.
Use this format:
If we give [specific user] the ability to [specific action], they will [observable behavior] because [underlying motivation].
A real example: "If we give freelance bookkeepers the ability to import a client's Shopify transactions in one click, they will pay $49/month because manual reconciliation is the most hated part of their week."
Test the sentence by reading it to someone outside your project. If they can repeat it back without paraphrasing, it's tight enough. If they can't, you have more work to do — and it's the most important work in the entire project.
Step 2: List every feature, then cut hard
Brain-dump every feature you've ever imagined for the product. Don't filter. Get all of them on the page — the obvious ones, the clever ones, the "we should also do X" ones.
Then run each feature through one question: does this feature directly test the hypothesis, or does it merely support a feature that does?
Only features that directly test the hypothesis survive. This will feel uncomfortably small. That is the entire point. Most founders cut about 60–70% of their original list at this step. The cuts are the strategy.
Two common objections, and how to handle them:
- "But users will expect [feature X]." Maybe. But expectation is not the same as need. If they can complete the core action without it, it's a v2 feature.
- "But it's only a few extra days." A few extra days, plus the meeting to scope it, plus the design pass, plus the QA, plus the regression risk, plus the cognitive load on every future decision. "A few days" is the most expensive phrase in MVP planning.
Step 3: Map the user journey end-to-end
For the surviving features, draw the full journey. Where does the user start? How do they hear about you? What's their first action? What does success look like? When do they come back?
This is not a wireframe. It's a sequence diagram in plain English. The point is to find the gaps — the moments where you assumed the user knew what to do, the places where you forgot they'd need to log in, the times you skipped the email verification step entirely.
Every gap you find at the journey-mapping stage is a gap you don't pay an engineer to discover at sprint review. The math on this is brutal: a gap caught here costs 30 minutes of your time. The same gap caught in sprint three costs a week of engineering and a redesign.
Step 4: Write the PRD
Now turn the journey into a document. Vision, hypothesis, target user, user stories with acceptance criteria, functional requirements, non-functional requirements, success metrics, and — most importantly — the explicit out-of-scope list.
Length target: 8–15 pages. Longer is procrastination. Shorter is under-specification. The PRD's purpose is to give designers and engineers enough constraint to do their best work without being told how to do their work.
If the PRD section structure is new to you, the canonical breakdown lives in the "What is a PRD?" essay. The short version: it is a contract between your current self and your future build team. Write it like one.
Step 5: Decide on monetization before you build
Even if you don't charge from day one, the monetization decision needs to be made before architecture is locked. The choice — subscription, transactional, marketplace fee, freemium — changes onboarding, instrumentation, what success looks like, and which flows get built first.
Concrete examples of how monetization shapes engineering:
- A subscription product needs billing, dunning, plan changes, and trial-to-paid conversion flows from day one.
- A transactional product needs payments at the point of value, refund handling, and probably some flavor of escrow or holding pattern.
- A marketplace needs payouts, fees, taxes, dispute resolution. Often more financial infrastructure than product surface area.
- A freemium product needs feature gating, limit enforcement, and an upgrade prompt experience that doesn't feel hostile.
Pick one. Commit. Write the first three pricing pages, even if you never publish them.
Step 6: Hand off, with the right artifact in hand
Now you talk to engineers. What you hand them determines what they quote.
If you walk in with a deck, you'll get an exploratory quote — a range, plus discovery time, plus contingency. It will be high because the engineering team is pricing in the cost of figuring things out as they go.
If you walk in with the artifact set from steps 1–5, you'll get a structured quote — a fixed scope, a tighter range, and dramatically lower contingency. The same engineering team often quotes 30–50% lower for the same idea, because they're estimating against a document instead of a feeling.
This is the moment the strategy work returns its investment. Up until now, it has felt like overhead. At handoff, it pays for itself, with interest.
What to skip
Founders new to MVP development often add steps that feel rigorous and aren't. A short list of things you do not need at this stage:
- A full design system. You need wireframes and brand basics, not a token library.
- A 50-page technical architecture document. A one-page approach is enough for MVP estimation.
- A burndown chart. You haven't started yet. Stop ceremonizing.
- A full competitive analysis matrix. You need to know your top three competitors and why you're not them. That's it.
- A pitch deck. Useful for raising money. Useless for building product.
The compounding effect
Every step in this playbook makes the next step cheaper and the eventual build faster. A clear hypothesis makes feature cuts easier. Easy cuts make journey mapping faster. A clean journey makes the PRD shorter. A short, sharp PRD makes the build quote tighter. A tight quote makes the build itself faster, with less rework, and a launch that looks more like what you imagined.
Founders who follow this sequence ship better products in less time at lower cost. Founders who skip it ship worse products in more time at higher cost. The math is not subtle.
If you'd rather not build this discipline from scratch, the Development Readiness Package is exactly this playbook, productized, with a deadline and a deliverable.