How to Build an MVP Before You Build a Full Product

Nick Swinmurn didn't build an online shoe store to start Zappos. He walked into local shoe stores, photographed their inventory, posted the photos on a basic website, and every time someone actually bought a pair, he drove back to the store, bought the shoes himself, and shipped them out.

No warehouse. No inventory system. No real backend. He was manually faking a business that would eventually sell for over a billion dollars, just to answer one question: will people actually buy shoes online without trying them on first?

That's what a real MVP looks like, and it's not what most first-time founders build. I want to walk through what actually counts as a minimum viable product, the different forms it can take depending on your business, and how to know when you've validated enough to stop faking it and start building for real.

What an MVP Is, and What It Isn't

A minimum viable product is the smallest, cheapest version of your idea that lets you test whether people actually want it, before you spend months and real money building the full thing. The word "product" trips people up here. An MVP doesn't have to be software at all. 

Dropbox offers another famous example. Rather than immediately releasing its early file-syncing product broadly, founder Drew Houston used a simple demonstration video to show potential users how Dropbox worked.

A later demo helped grow its beta waiting list from about 5,000 to 75,000 people, giving the company a powerful signal that people wanted the experience before it was ready for a wider launch.

I think the mistake founders make constantly is treating "minimum viable" as "smaller version of the full product" instead of "the smallest possible test of the riskiest assumption."

Those are genuinely different things. A smaller version of your app still takes months to build. A real test of your riskiest assumption, will people pay for this, will they actually use it the way you think, can sometimes be built in days.

Also Read: How to Start a Business While Working a Full-Time Job

The Different Forms an MVP Can Take

Depending on what you're actually trying to validate, an MVP can look like several different things, and picking the wrong type wastes exactly the time and money you're trying to save.

A landing page MVP is a simple page describing your product, with a signup form or a pricing button, built specifically to gauge whether people are interested enough to hand over an email address or a card number before anything else exists.

Buffer used exactly this approach, testing whether people would actually pay for a social media scheduling tool before writing a single line of the scheduling engine itself.

A concierge MVP means you deliver the service by hand, personally, to a small number of early users, no automation at all.

It's labor-intensive per customer, but it teaches you exactly where the real friction and value sit, which is often invisible until you're doing the work yourself.

A Wizard of Oz MVP is what Zappos actually was. The customer sees something that looks like a real, functioning product, but a human is manually doing the work behind the scenes.

It's the sharpest way to test actual purchase behavior without building the operational infrastructure a real version would require.

A single-feature MVP strips the idea down to the one function that delivers its core value and launches without the additional features planned for later versions.

The goal isn't to create an intentionally bad product; it's to find out whether users actually value the central function before investing in everything around it.

Also Read: How to Write a Business Plan That Actually Attracts Investors

What You're Actually Testing

Before you build anything, get specific about the one assumption you're most worried about being wrong. For Zappos, it was whether people would buy shoes sight-unseen online.

For Airbnb, it was whether strangers would actually pay to sleep in someone else's home, a question Brian Chesky and Joe Gebbia tested by renting out air mattresses in their own living room during a conference when local hotels were sold out.

All three spots filled immediately, and that alone told them the core assumption behind the entire business held up.

Notice what neither of these founders did. They didn't build a polished platform first and hope the assumption held.

They found the cheapest, fastest way to get a real answer, with real money or real behavior involved, not just opinions from friends and family who'll tell you what you want to hear regardless of whether the idea actually works.

How Do You Know What to Cut?

This is where I see founders get stuck most often. Here's the test I'd apply. For every feature you're considering building into version one, ask whether the business idea fails to get validated without it.

If the answer is no, cut it. Zappos didn't need real-time inventory sync, a return policy engine, or a mobile app to answer its core question. It needed a webpage and a car.

I'd also separate what proves demand from what proves a working business. A Dropbox-style demo video proves people want the outcome. It doesn't prove they'll pay a sustainable price for it, or that you can actually deliver it profitably at scale.

Product Hunt's original MVP was literally a daily email digest, curated by hand, that founder Ryan Hoover sent to a small group of tech enthusiasts to test whether a community around product discovery had real pull before any platform existed.

That validated interest. It took a real platform, built afterward, to validate the business. Match the type of MVP to the type of risk you're actually worried about. If your biggest fear is that nobody wants this, a landing page or a demo video answers that cheaply.

If your biggest fear is that you can't actually deliver the service well, a concierge MVP, doing it manually for a handful of real customers, answers that instead.

Building the wrong kind of MVP for the risk you're actually facing is how founders end up with a validated idea and no idea whether they can actually run the business behind it.

Also Read: Stop Working 14-Hour Days - The Productivity Stack Every Entrepreneur Needs

When Should You Start Building the Full Product?

I don't think there's a universal number of signups or a magic revenue figure that tells you it's time. What I'd look for instead is whether your manual, faked version is starting to break under its own weight.

Zappos moved from manually buying shoes at local stores to real inventory relationships once the volume of orders made the manual approach genuinely unsustainable, not before.

That's the signal. The MVP has done its job once maintaining it by hand costs you more time and money than building the real version would.

I'd also watch for a second signal: whether the feedback you're getting has shifted from "does this solve my problem" to "I wish it also did X."

Once early users are asking for expanded functionality rather than questioning whether the core idea works at all, that's a strong sign the fundamental assumption has been validated, and you're now in product development territory, not validation territory anymore.

Resist the urge to keep validating forever out of fear. I've watched founders stay in MVP mode for a year past the point they'd already gotten a clear answer, using "more testing" as cover for avoiding the harder, riskier work of actually building and scaling.

If your core assumption has held up across a real sample of paying or actively engaged users, more validation isn't reducing your risk anymore. It's just delaying the next, harder decision.

Also Read: Top AI Automation Tools to Scale Your Business - From Workflows to Autonomous Agents

Final Thoughts

The founders behind Zappos, Dropbox, Airbnb, and Amazon weren't running lean because they lacked ambition or resources.

They were running lean because they understood that building the wrong full product is a far more expensive mistake than any amount of manual, unscalable effort spent finding out whether the idea works in the first place.

Before you write a business plan or hire a developer, figure out the one assumption that would sink your entire idea if you're wrong about it, then find the cheapest, fastest, most honest way to test exactly that. Everything else can wait until you've actually earned the right to build it.