You can spend $0 and ship your minimum viable product for startups in a weekend. You can also spend $200,000 and eleven months building one that nobody wants. I've watched both happen up close, and the expensive version fails more often.
That gap is the whole story of the minimum viable product (MVP). The concept isn't complicated — it's the execution that gets people. Most founders I talk to understand the theory perfectly and then build the wrong thing anyway, because it's psychologically painful to ship something ugly and small when you have a beautiful, full-featured product in your head.
Here's what I've learned after working on more MVPs than I care to count — some that validated brilliantly, some that validated nothing but taught me the expensive way.
Key takeaways
- An MVP is the smallest thing you can build that tests one core assumption about customer behavior — not a scaled-down version of your final product.
- Scope discipline matters more than technical skill: most MVPs fail because the founder builds the wrong 20%.
- Realistic budget for a first MVP sits somewhere between $0 and $15,000 for most software startups, and time-to-MVP should be measured in weeks, not quarters.
- If your MVP doesn't feel a little embarrassing to show, you probably over-built it.
What is a minimum viable product in a startup?
A minimum viable product is the most stripped-down version of your idea that still delivers real value to a real person and generates a real signal — willingness to pay, willingness to return, willingness to recommend. That last part is where definitions usually go soft. People say "value" and forget "signal."
The signal is the point. Not the product.
I made this mistake personally. In one of my early projects I built a task-management tool, spent six weeks on a lovely interface, and launched to a handful of users who politely said it was "nice." They didn't come back. I had validated that people would log in once, which I already knew. Had I built a landing page with a waitlist and a two-question survey, I would have learned the same thing in a day.
The MVP isn't a prototype
Worth clearing up because the two get used interchangeably. A prototype proves that the product can be built. An MVP proves that people will use it. You can have a beautiful prototype and a worthless MVP, because the prototype never touches a real customer's wallet or time.
Real MVPs come in shapes that surprise people who think "product" means "app with a dashboard":
- A landing page with a payment form and a waitlist
- Concierge service — humans doing manually what software will eventually do
- A spreadsheet and a Slack channel
- A single-feature tool that does exactly one job extremely well
- A video demo of something that doesn't exist yet
I've seen a founder validate a B2B compliance tool by running it entirely through email and a shared Google Sheet for six weeks. Two paying customers, $1,800 in revenue, no code written. That's an MVP.
How do startups build an MVP?
The build itself is usually the easy part. The hard part is deciding what to build and what to cut. Here's the sequence that has worked for me, adapted a dozen times depending on the context.
Step 1: Write down your riskiest assumption
Every startup rests on several assumptions at once — that the problem exists, that people will pay to solve it, that you can reach them, that you can deliver profitably. Rank them by how badly things break if the assumption is wrong. The one at the top is what your MVP must test.
Concretely: if your risk is "will anyone pay $30/month for this," build a pricing page and a checkout flow. If your risk is "can I reach my audience at all," build the landing page and run traffic to it. Those are different MVPs for the same eventual product. This step is also where you'll discover your real question — most founders skip it and test something comfortable instead.
Step 2: Define the viability threshold before you build
This one changed my approach more than anything else. Decide, in advance, what result counts as a go. Not "we'll see" — a number. Something like: 100 visitors to the page, a 4% conversion to email, and at least 3 people asking when it launches.
Without a pre-committed threshold, founders rationalize. I've watched someone interpret two sign-ups and a supportive tweet as "traction." They shipped a full product to an audience of three.
Step 3: Cut scope using the 80/20 rule
Which brings up the question everyone asks. The 80/20 rule for startups says that about 80% of the value your product delivers comes from 20% of its features. Your job in an MVP is to find that 20% and build only it. Everything else waits.
The practical method: list every feature you imagine. Then ask of each one, "if I delete this, can the user still complete the core action?" If yes, delete it. Then delete one more, because you were being generous.
Prioritization frameworks help here — MoSCoW (must/should/could/won't), RICE scoring, Kano analysis. My honest take: for a first MVP, MoSCoW is enough, and the "W" column should be dramatically bigger than the other three combined. RICE rewards the founders who most enjoy spreadsheets, not necessarily the best decisions.
Step 4: Build in the cheapest form that tests the assumption
No-code tools have collapsed the cost of this. Today, a founder with no engineering background can ship a landing page, a form, a payment link, and a basic workflow in two or three days. I'm convinced that at least half the software startups I've encountered could have tested their core hypothesis with zero custom code.
Custom development becomes necessary when the core value depends on complex logic, data, or scale. Even then — build it narrow. One feature, done properly, beats five features done adequately.
Step 5: Ship to real strangers and measure
Friends and family are not data. They're moral support. Get in front of people who don't owe you a favor, watch them try, and count what happens against your pre-committed threshold. Then resist the urge to explain away the result.
How much does it cost to build an MVP?
Direct answer: anywhere from $0 to roughly $20,000 for most early-stage software startups, with the majority landing under $5,000 if they use existing tools and don't hire a full agency. Here's how that breaks down in practice.
| Approach | Typical cost | Time to launch | Best for |
|---|---|---|---|
| No-code (forms, landing pages, automations) | $0 — $200/month in subscriptions | 2 days to 2 weeks | Testing demand and pricing assumptions |
| Freelance developer, single feature | $3,000 — $12,000 | 3 — 8 weeks | Products where the core value needs custom logic |
| Agency or small studio | $15,000 — $50,000+ | 2 — 4 months | Founders with budget but no technical co-founder |
| Co-founder builds it | Time and equity | Highly variable | Technical founders — the cheapest option by far |
Two things inflate these numbers in real life. First, scope creep masquerading as "just one more feature" — I've seen an MVP budget double that way without anyone noticing. Second, picking the wrong build partner. Cheaper isn't always faster, and an agency that doesn't understand MVPs will happily build you the full product because that's what they know how to sell.
Notice something missing from that table: a line for "designing a brand identity and a website." Those are not MVP activities. They can wait until you know the thing is worth branding.
Types of MVP and how to pick
The right format depends almost entirely on what you're trying to learn. Same product concept, different risk, different MVP.
- Landing page MVP — tests demand and messaging. Cheapest possible signal.
- Concierge MVP — you deliver the service by hand. Perfect for validating a workflow before automating it.
- Wizard-of-Oz MVP — users think it's automated, a human is behind the curtain. Tests the same thing as concierge but feels more like a product.
- Single-feature MVP — one narrow tool solving one specific problem extremely well.
- Crowdfunding or pre-sale MVP — real money as real validation. Brutal and honest.
My rule of thumb: pick the cheapest format that produces a signal you would actually trust. Landing pages are cheap but sometimes produce weak signals — people click "sign up" for anything free. Pre-orders are uncomfortable but unambiguous.
The mistakes I made (and you probably will too)
Real talk: I've built at least three MVPs that were over-engineered. Every one of them followed the same pattern. I got excited about the product's potential, started adding "obviously essential" features, and lost four to eight weeks of the calendar. By the time I launched, my interest had faded and the assumptions had shifted.
The most expensive one cost me roughly six weeks and about $4,000. It validated nothing, because by the time it existed I'd lost track of what question I was trying to answer. That's the failure mode nobody warns you about: not building something bad, but building something good that answers the wrong question.
The other trap is elegant on paper and painful in practice — treating MVP launch as a milestone rather than the start of a loop. The build-measure-learn cycle only works if you actually measure and then actually rebuild. An MVP that never gets iterated on is just an unfinished product with a fancy name.
What matters most
Every good MVP I've seen shares the same trait: it was built by someone who knew exactly what they wanted to learn and was willing to look foolish for a few weeks to learn it. Every bad one was built by someone who wanted the product to be finished.
The MVP isn't a smaller version of the thing you want. It's a question, dressed up as a product. If you can't state your question in one sentence, you're not ready to build — you're ready to think.
The question worth asking yourself right now isn't "what should I build first?" It's "what would I need to see to walk away?" Answer that honestly, and the scope of your minimum viable product tends to define itself.
