A few months ago, an entrepreneur sat across from me with a notebook full of features. She wanted a full booking system, a loyalty program, a mobile app, an admin dashboard, and a customer portal, all before she had sold a single ticket. She had budgeted for everything. She wanted to write one big check and launch a complete product on day one.
I understand that instinct. When you believe in an idea, you want it to be excellent right away. But this is the exact moment I bring up something that changes the whole plan: the MVP.
What MVP Actually Means (No Jargon, Promise)
MVP stands for Minimum Viable Product. Strip away the acronym and it means something simple: the smallest version of your idea that real people can actually use and pay for.
Not the smallest version that looks impressive in a slide deck. The smallest version that works well enough to test whether your core idea is true.
The term comes from the book The Lean Startup, where author Eric Ries described an MVP as the version of a product that lets you learn the most about your customers with the least amount of work. It is not about building something cheap or half-broken. It is about building the one thing that proves your big idea, so you do not spend a fortune guessing.
Why Testing the Core Idea First Saves Money (and Heartbreak)
Here is the hard truth I have watched play out more than once: most of the features on that long wish list will not get used the way you imagined. Some customers will want something you never thought of. Others will ignore the feature you were proudest of.
If you build everything first, you find this out after you have spent the whole budget. If you build the smallest useful version first, you find it out while you still have money, time, and options left.
Think about it this way. Would you rather spend a large sum finding out your idea needs a different approach, or a small fraction of that to learn the same lesson? An MVP is how you buy that information cheaply, before it becomes an expensive surprise.
This is not about thinking small forever. It is about sequencing your investment so the big decisions come after you have real answers, not guesses.
What to Cut for Your First Version (and What Not to Cut)
This is where most people get nervous. Cutting features can feel like admitting the idea is smaller than they imagined. It is not.
Safe to cut from version one:
- Anything nice to have that is not the reason someone would choose your product
- Admin dashboards and detailed reports, before you have real data worth reporting on
- Support for rare edge cases that affect only a handful of users
- Extra themes, custom branding options, and configuration screens
- Integrations with other tools, unless the integration is the whole point
Do not cut:
- The one thing that makes a real customer say yes and pay for it
- Basic security and protection of customer data
- A simple, working version of the core action your product exists to perform
If you are building a scheduling tool, the core action is booking an appointment. Reminders, reports, and staff calendars can wait. If the booking flow does not work smoothly, nothing else matters anyway.
A Real MVP Done Well
Airbnb is one of the clearest examples. In 2007, its two founders could not afford rent in San Francisco. A design conference was in town, and every nearby hotel was full. So they bought a few air mattresses, put them on their apartment floor, and offered a place to sleep, a homemade breakfast, and some local advice through a simple website they built themselves.
There was no app. There was no booking calendar. There was barely any payment processing. Just a test of one question: would strangers pay to sleep on an air mattress in someone else's apartment? The answer was yes. That answer, not a finished product, is what convinced the founders to keep going.
Dropbox tells a similar story. Before the founder built much of the actual product, he recorded a short video showing how the file-syncing idea would work and posted it online for early adopters to see. The waiting list grew almost overnight. That told him people wanted the idea before a single piece of the full product existed.
Neither company launched the whole thing first. Each one launched the smallest version that could answer its biggest question.
An Everyday Way to Think About It
Imagine you want to open a restaurant. You have a dream menu with forty dishes, a full bar, and a private dining room. Instead of building all of that at once, you start with a food truck and five dishes.
You learn which two dishes people actually order. You learn what they are willing to pay. You learn which days are busy and which locations work. Only then do you sign a lease, hire a bigger staff, and build out the rest of the menu.
The food truck is not a cheap version of your restaurant. It is the smart first step that tells you exactly what the real restaurant should become.
Software works the same way. Your MVP is the food truck. The full platform can come later, once you know what people genuinely want.
Where This Fits Into Your Bigger Plan
An MVP is not the end of the journey. It is the beginning of an informed one. Once you know your core idea works, you are in a much better position for the planning conversations that come next, like the ones I walk clients through during a discovery phase, and for growing the product piece by piece, the way I describe in building now and growing later.
The order matters. Test small first. Plan and expand once you know real people want what you are building.
If you are sitting on a big idea and wondering how small your first version could actually be, I would love to help you figure that out.