MVP Planning Template

10

Template Sections

60+

Fill-in Fields

Real

Examples Included

Free

No signup needed

The instinct is to build many features. The discipline is to build one feature that perfectly solves one problem. Resist scope creep at every decision point.

An MVP that launches in 6 months is not an MVP. If your scope requires more than 8 weeks to build, cut features until it fits. Speed to market is a competitive advantage.

Your primary persona should feel like the product was built specifically for them. A product for everyone converts nobody. Go narrow first, broad later.

Set up analytics before launch, not after. You need data from your first user. Optimising without data is guessing. Guessing is expensive.

The most common MVP mistake is building too much before talking to users. Run 10–20 user interviews before writing a single line of code. What you learn will change what you build.

Perfect is the enemy of shipped. Your first version will look worse than you want. That is fine. Real user feedback is infinitely more valuable than imagined perfection.

Problem Definition

Every successful product starts with a clearly defined problem. If you cannot articulate the problem in one sentence, you are not ready to build.

Hint: One to two sentences. Describe the pain, who experiences it, and how often.

Hint: Be specific. Avoid 'everyone' — narrow targeting leads to better products.

Hint: This defines your competition — including manual workarounds.

Hint: The gap between current solutions and your opportunity.

Hint: Your unfair advantage or the insight others have missed.

User Personas

Define exactly who you are building for. A product built for everyone serves no one. Your primary persona drives every feature decision.

Hint: Give them a name. It makes decision-making concrete.

Hint: What does this person want to achieve in their work and life?

Hint: Their pains — the things that make their current situation frustrating.

Hint: Where you will find and reach them for distribution.

Hint: Optional. Only define a secondary persona if they have meaningfully different needs.

Hint: Being explicit about who you are not building for prevents scope creep.

Value Proposition

Your value proposition is the single clearest statement of why your product exists and why someone should choose it over alternatives.

Hint: Format: [Product] helps [persona] [achieve outcome] by [mechanism]. Must be specific and outcome-focused.

Hint: Quantify the value you deliver. Numbers build credibility.

Hint: Why choose you over the alternatives you listed in Section 01?

Hint: Write your headline now — it forces clarity on your value proposition.

Feature Scoping (MoSCoW)

Use the MoSCoW method to ruthlessly prioritise what ships in your MVP. Everything not in Must Have gets cut until after launch.

The product does not function without these. Core user journey must be completable end-to-end.

e.g.
• User signup and login with email
• Create a new project brief (form)
• AI generates proposal from brief
• Edit proposal text inline
• Send proposal link to client
• Client can view and accept proposal
• Stripe payment link in proposal

Important but not critical for first launch. Build these in the first 2 weeks post-MVP.

e.g.
• PDF export of proposal
• Custom branding (logo, colours)
• Proposal status tracking (viewed, accepted, declined)
• Email notification when client views proposal
• Multiple proposal templates by project type

Nice to have if time and scope allow. Include only if Must Haves are complete ahead of schedule.

e.g.
• CRM integration (HubSpot, Pipedrive)
• Client e-signature on proposal
• Proposal analytics (time spent viewing)
• Team workspace with multiple users
• Proposal version history

Explicitly out of scope. Writing this down prevents scope creep during development.

e.g.
• Native iOS/Android app
• Full accounting/invoicing suite
• White-label reseller programme
• API access for third-party developers
• Multi-currency billing

Technical Stack

Choosing your tech stack early prevents costly rewrites later. Choose boring, proven technology over cutting-edge unless your product specifically requires it.

Hint: Recommendation: Next.js for most SaaS products. Avoid over-engineering the frontend.

Hint: Recommendation: Supabase for most MVPs. Gives you auth, DB, storage, and edge functions in one.

Hint: Do not build your own auth. Use Supabase Auth, Clerk, or NextAuth.

Hint: Use Stripe for payments in almost every case. Integrate early — billing is complex to add later.

Hint: Resend or Postmark for transactional. Loops or Customer.io for marketing automation.

Hint: Vercel + Supabase is the fastest path to production for most Next.js MVPs.

Hint: Claude for instruction-following tasks. OpenAI for multimodal. Consider costs at scale.

Hint: Set these up before launch, not after. You need data from your very first user.

Success Metrics

Define what success looks like before you build. If you cannot measure it, you cannot improve it. These metrics guide every product decision post-launch.

Hint: The single number that best represents value delivered to users. Everything should move this metric.

Hint: The action that signals a user has experienced your core value for the first time.

Hint: Retention is the strongest signal that your product delivers ongoing value.

Hint: Define a specific MRR target with a deadline. Vague goals produce vague results.

Hint: Write the specific numbers that would make you confident your MVP has validated product-market fit.

Hint: Define the signal that tells you to stop, pivot, or kill the product. Knowing this in advance prevents wasted effort.

Build Timeline

A realistic timeline keeps your team aligned and your budget predictable. Work backwards from your launch date.

Hint: Pick a real date. A fixed deadline creates the forcing function to scope decisions correctly.

Hint: Technical foundations that everything else is built on. No feature work until this is solid.

Hint: The Must Have features from your MoSCoW list. This is the core user journey.

Hint: Without billing, you cannot charge. Without polish, users drop off before they see value.

Hint: Never ship without a QA week. Budget for 15–20% of your timeline for testing and fixes.

Hint: The features that did not make MVP scope but are important for retention and growth.

Budget Estimate

Estimate costs across all categories before starting. Surprises in budget are worse than surprises in scope.

Hint: Agency: $15k–$80k. Freelancer: $10k–$40k. In-house team: $30k+ in salary equivalent.

Hint: Infrastructure costs should be under $100/month for most MVPs. Avoid over-provisioning.

Hint: List all paid APIs and services. Estimate at 500 and 5,000 users to understand scaling costs.

Hint: Even if marketing is organic, budget time. Content creation, outreach, and community management have a real cost.

Hint: Always budget contingency. The only question is whether you do it upfront or get surprised later.

Hint: Your total budget defines your runway. Ensure you have at least 3–6 months of personal runway beyond this.

Go-To-Market Strategy

Distribution is as important as the product. Define your first acquisition channels before you build — it affects what you build.

Hint: Pick one channel and go deep. Spreading across many channels at MVP stage produces weak results.

Hint: Plan your launch day post. Have 20+ supporters lined up to upvote on Product Hunt.

Hint: A waitlist turns launch day from a cold start to a warm audience ready to activate.

Hint: Do things that do not scale. Your first 10 customers should be acquired manually.

Hint: SEO compounds over time. Starting before launch means organic traffic at launch.

Hint: Start higher than you think. It is easy to discount; hard to raise prices on existing customers.

Risk Assessment

Identify your biggest risks before you start building. A risk identified is a risk managed — a risk ignored becomes a crisis.

Hint: The assumption your product is most dependent on being true.

Hint: Is there enough demand? Is the TAM large enough to build a sustainable business?

Hint: The technical assumption that, if wrong, would require the most rework.

Hint: What happens if a big player copies your feature? What is your moat?

Hint: List the specific actions you will take to reduce risk before or during the build.

Done planning? We build it.

This template was built from our experience scoping and shipping 45+ MVPs, SaaS products, and web applications. We use this exact framework internally before every build.

If you have completed this template and are ready to build, we can take your plan and ship your MVP in 28 days on a proven Next.js + Supabase + Stripe stack.