The Minimum Viable Product Playbook: What to Ship and What to Skip

The Minimum Viable Product Playbook: What to Ship and What to Skip

The MVP concept has been so thoroughly misused that many founders now build minimum viable products that are neither minimum nor viable. They are over-built products with too many features, delivered too slowly, tested too little, and validated not at all.

This playbook returns to first principles. What an MVP is actually for, how to scope one ruthlessly, which features are almost never necessary in version one, how to choose the right technology, and the definitive test for whether what you have built is truly viable.

What an MVP Is Actually For

An MVP is not a small version of your full product. It is the smallest possible product that answers the question you most need answered.

That question is almost always: will real people use this to solve a real problem well enough that they will come back or pay for it?

Notice what the question does not include:

• Whether the product is beautiful
• Whether it scales to 100,000 users
• Whether it has every feature on your roadmap
• Whether your investors are impressed by the demo

The MVP is a learning instrument. It is built to generate information, not to generate revenue (though revenue is the most valuable kind of information). Every feature in an MVP should serve the question you are trying to answer. Features that do not serve that question are waste.

If you want help scoping your MVP before you start spending, use the MVP Planner to map the core user journey and identify exactly what needs to be built.

Define the Core Value Proposition in One Sentence

Before you scope a single feature, you must be able to state your core value proposition in one sentence. Not a marketing sentence - a functional sentence.

Format: "[Product name] helps [specific user type] to [do the core thing] so that [they achieve the core outcome]."

Example: "Invoicr helps freelance designers to create and send invoices in under two minutes so that they get paid without administrative friction."

If you cannot write this sentence cleanly, you are not ready to scope an MVP. The product is not yet clear enough in your own mind to build it.

Everything in the MVP should directly serve this sentence. If a feature does not help the specific user type do the core thing or achieve the core outcome, it does not belong in version one.

Scoping an MVP with the MoSCoW Method

The MoSCoW method categorises every proposed feature into four buckets:

• Must Have: The product cannot fulfil its core value proposition without this. If it is missing, the MVP is not viable.
• Should Have: Important, but the product still works without it. These go in sprint two.
• Could Have: Nice to have, will not significantly impact the core. Backlog for later.
• Won't Have (this time): Explicitly excluded from version one. Writing this list is as important as writing the Must Have list.

Run every proposed feature through this filter. Be brutal. The instinct is to inflate the Must Have list. Push back on yourself: "What happens if we launch without this?" If the answer is "users still get the core value," it is not Must Have.

A well-scoped MVP typically has four to eight Must Have user stories. If you have twenty, you have not prioritised.

The Five Features Most MVPs Include That They Should Not

1. User Roles and Permissions

The MVP serves one type of user. Adding role-based access control before you have validated the core product adds weeks of development and significant complexity. Build it when you have actual customers with actual role requirements.

2. Advanced Settings and Customisation

Every product eventually needs customisation. But at MVP, the default should be opinionated and simple. Customisation is what you build when you understand what users actually want to customise - which you can only learn after they have used the product.

3. Email Notification System

A basic transactional email (sign-up confirmation, password reset) is fine. A full notification preference system with digest options and channel selection is not an MVP feature. Use a simple managed email provider and send notifications from a simple template until you understand what notifications actually matter.

4. Admin Dashboard and Analytics

You are the admin. At MVP stage, look directly at the database or use your analytics tool. A custom admin dashboard is overhead that delays the real product.

5. The Mobile App

Unless your product is genuinely mobile-first (navigation, camera, real-time location), build web first. A well-designed responsive web app covers 80% of mobile use cases at 20% of the development cost. Build the mobile app when users demand it.

Deciding on Tech Stack for an MVP

The right tech stack for an MVP is the one your team knows best and can move fastest with. This is almost never the most fashionable choice.

The questions that matter:

• What does your development team already know well?
• How quickly can you ship changes and deploy updates?
• What is the overhead of the chosen stack? (A framework that requires boilerplate setup for every new feature slows you down at MVP stage)
• Does the stack have managed services for things you should not build yourself (auth, storage, email)?

The Tech Stack Picker can guide you through these decisions based on your product type and team experience.

General MVP stack principles:

• Use a relational database (PostgreSQL) unless there is a specific reason not to
• Use managed authentication (Auth0, Clerk, Supabase Auth) - do not build auth from scratch
• Use a managed hosting platform (Vercel, Railway, Render) - do not manage servers at MVP stage
• Use an established framework for your frontend (React, Next.js, Vue) - the community support is valuable when you hit edge cases

MVP Timelines by Product Type

These are realistic timelines for a small, experienced team:

Timelines assume a team of two to three developers working full-time on the MVP, with a clear PRD. Without clear requirements, add 30-50% to any estimate.

If these timelines feel long for your runway, custom software development with an offshore team can deliver the same output significantly faster because you are adding developer bandwidth without the ramp-up time of new hires.

How to Test Your MVP with Real Users

Testing starts before launch. Before you push the product live to the public, you should have real users from your target segment go through the core flow with you watching.

Usability testing at MVP stage is simple:

1. Find five people who match your target user profile (not friends, not family)
2. Give them a single task that represents the core user journey
3. Watch them try to complete it without helping them
4. Note where they pause, click the wrong thing, or give up

Five usability tests will surface most of the major problems in your MVP. Fix those before you open the product more broadly.

After you open to a wider group (even 20-30 people), track:

• Activation rate: what percentage of signups complete the core flow?
• Day 7 return rate: of users who activate, what percentage come back after one week?
• Time to value: how long does it take from sign-up to the moment a user gets value?

These three metrics will tell you more about whether your MVP is viable than any feature checklist.

What Makes an MVP "Viable" vs Just "Minimum"

"Minimum" is easy. Strip everything out until the product barely exists. The harder word is "viable."

Viable means users can get real value from the product independently, without intervention from the founder. It means the core user journey works end-to-end without bugs. It means a user who has never heard of your company can sign up, onboard, and reach the "aha moment" without your help.

Test for viability with the "stranger test": give five people who have never heard of your product a link to sign up, tell them nothing, and watch what happens. If more than 40% of them successfully complete the core flow and express that they got value, your MVP is viable.

If they cannot figure out what to do, your onboarding is broken. If they figure it out but do not find it valuable, your product is broken. Both are fixable - but both are failures of viability, not minimalism.

The Launch Decision

You are ready to launch when:

• The core flow works end-to-end without bugs
• At least five real target users have successfully used it and expressed value
• You have analytics installed
• You have a way to receive feedback (email, in-app chat, survey)
• You know what success in the first 30 days looks like and how you will measure it

You are not ready to launch when:

• The product only works in demo scenarios
• Users need your guidance to complete the core flow
• You have not set up tracking

The MVP playbook is simple to describe and hard to follow. The temptation to add one more feature, polish one more interaction, delay one more week is constant. The founders who ship great MVPs are the ones who resist that temptation, get the product in front of real users, and treat user behaviour as the only feedback that matters.

Use the MVP Cost Calculator to estimate your build cost, and get a free quote when you are ready to start.