There's a mental trap every founder falls into at least once: the belief that shipping later with more features is safer than shipping now with less.
It's not. It's exactly backwards.
The longer you build before talking to customers, the more you're betting on your assumptions being correct. And most assumptions are wrong. Not slightly wrong. Wildly, fundamentally, expensively wrong.
The MVP — minimum viable product — is a corrective. It's the smallest thing you can build that lets you test your core hypothesis with real people. Not your friends. Not your advisors. Real people who have the problem you're solving.
This matters because building more features doesn't fix a broken hypothesis. It just makes the broken hypothesis more expensive and harder to pivot.
What MVP Actually Means (And What It Doesn't)
Eric Ries, in The Lean Startup, defined MVP as "the version of a product with just enough features to satisfy early customers and validate core hypotheses with minimum resources."
Notice what's in that definition: hypotheses. You're not building a complete product. You're building a test. The goal isn't shipping something beautiful. It's learning something true fast.
This is where the term gets misused. A lot of founders interpret "minimum viable" as "shipped fast and half-baked." And that's partially right — speed matters. But "viable" is the key word. It has to actually work. It has to actually solve the problem you claim to solve. It just doesn't have to solve every problem or solve it perfectly.
Think of it this way:
- Minimum: You're building the least you possibly can.
- Viable: It actually works and delivers the core value.
- Product: It's a real thing people can use, not a prototype or concept.
A broken product that you ship in a week isn't an MVP. It's a failed MVP. An MVP works. It's just small.
The Spectrum of MVPs
There are multiple ways to validate a hypothesis without building a full product. Think of these as points on a spectrum:
Landing Page MVP: No product at all. Just a description of your idea and a sign-up button. You're testing if people are interested in the solution before you build it.
This is the fastest and cheapest way to validate demand. If 100 people land on your page and only 2 care enough to sign up, your hypothesis might be wrong. If 100 people land and 25 sign up? You've got something.
Wizard of Oz MVP: The product appears automated, but there's a human behind the scenes pulling the levers.
Zappos did this. Instead of building a full e-commerce site, they took pictures of shoes from retail stores, posted them online, and manually fulfilled orders from those same stores. They were testing "Do people want to buy shoes online?" before investing millions in inventory and logistics.
Concierge MVP: You deliver the core value through personal service, not product.
This is powerful because it teaches you exactly how your customers want to use your product. You're the product at first. Then you automate what you've learned.
Single-Feature MVP: You build a real product with one core feature. Everything else gets cut.
Slack started as an internal tool for a gaming company. They released it with one feature: group messaging. No video. No integrations. No hundreds of features. Just messaging that worked really well.
Prototype MVP: A semi-functional version that demonstrates the core idea but isn't fully built out.
This is riskier because people can't actually use it long-term, but it's useful if you need to show instead of tell.
The best choice depends on what you're testing. If you're testing market demand, a landing page MVP makes sense. If you're testing user behavior, you need something actually functional. If you're testing implementation difficulty, a prototype might be enough.
Famous MVPs: Learning From What Actually Happened
Dropbox: Drew Houston filmed a 3-minute video showing how file syncing worked. He posted it to Hacker News. That video taught people what his product did faster than thousands of words. People signed up. Then he built the product.
Airbnb: Before they had a real platform, the founders rented out air mattresses in their own San Francisco apartment during a packed design conference, then went city by city meeting early hosts and shooting listing photos themselves. They learned what made a listing convert before they wrote the code to scale it.
Craigslist: Started as a mailing list sent by one person to a few hundred friends. It was literally just emails. No site. No algorithm. No safety features. Just a list of things people wanted to buy and sell.
Instagram: Could have been a location check-in app with photo sharing on the side (that was Burbn). Instead, they stripped everything away and shipped with just photos and likes. That single focus became a $1 billion product.
Twitch: Wasn't originally a gaming platform. It started as Justin.tv, a life-streaming website. People kept streaming video games. The founders noticed the pattern. They stripped everything and focused on gaming. The specific market shaped the product, not the other way around.
Notice what all of these have in common: they started with the smallest possible expression of the core idea, shipped it, and let customer behavior guide what came next. None of them launched with the full vision.
Identifying Your Core Value Hypothesis
Before you can build an MVP, you need to know what you're testing.
Your core value hypothesis is one sentence: "If [type of person] had [solution], they would [desired outcome] because [reason]."
"If solo founders had a tool to generate business plans quickly, they would launch 2x faster because they'd skip months of planning."
"If remote teams had better async communication, they would need fewer meetings because context would be documented and searchable."
Your MVP is designed to test this one thing. Everything else is noise.
Most founders make the mistake of trying to test multiple hypotheses at once. "We're building a project management tool for remote teams that has AI-powered insights and integrates with Slack and has offline-first sync and..." No. Test one thing. Everything else is distraction.
Ask yourself: if I could only test one thing, what would need to be true for this to work?
That's your core hypothesis.
The Build-Measure-Learn Loop
This is the engine that turns an MVP into a real product:
- Build: Create the smallest thing that tests your hypothesis.
- Measure: Release it and see what actually happens.
- Learn: Gather feedback and data.
- Repeat: Start again with what you learned.
This shouldn't take three months per cycle. It should take one to two weeks.
Week 1: Build something. Ship it. Week 2: Measure. Talk to users. Understand what they loved and what they hated. Week 3-4: Learn and adjust. Launch next iteration.
This rapid iteration is what separates successful startups from ones that spend six months building in a cave then wonder why customers don't care.
Measuring the Right Things (Not Vanity Metrics)
Here's what doesn't matter: page views. Sign-ups. Downloads. These are vanity metrics. They feel good but they don't predict success.
Here's what does matter:
Engagement: Are people actually using the core feature? If you ship a project management tool, are people creating projects and inviting teammates? Or are they signing up and never coming back?
Track: Daily active users. Features actually used. Time spent. Repeat usage.
Retention: Do people come back?
If 1000 people sign up but only 50 are still using your product after a month, that tells you something's wrong. It doesn't matter how many people signed up.
Track: Week 2 retention. Week 4 retention. Which cohorts stick around?
Willingness to pay: Do people care enough to pay for this?
You don't need a payment system yet. Ask them. "Would you pay $50/month for this?" matters way more than how many free sign-ups you get.
Track: NPS (would you recommend this to a friend?). Survey responses on willingness to pay. How many beta users request pricing?
These three metrics tell you if you've found something real or if you're building for an audience that doesn't exist.
When Your MVP Is Done (Spoiler: Never)
This is the question founders always get wrong. "When is the MVP done?"
Never. An MVP is never done. It's done when you know your hypothesis is either validated or proven false. That usually takes 2-6 weeks of real usage.
You're not done when you've built everything you planned. You're done when you've learned something fundamental about whether your hypothesis was right.
If you learn "people love this, here's what we should build next," you move to the next iteration.
If you learn "nobody cares about this problem," you pivot or you stop.
The worst outcome is building for three months then shipping something that's technically complete but nobody wants. That happens because you never tested the hypothesis. You just built.
Common MVP Mistakes
Building too much: You added features because they seemed cool, not because they test your hypothesis. Every feature delays learning.
Building too little: You built something so stripped-down that it doesn't actually work. Nobody can judge a product they can't use. "Viable" matters.
No clear hypothesis: You shipped something but you're not sure what you're testing. That means your measurement will be meaningless.
Talking to the wrong people: You showed your MVP to friends and coworkers who are biased in your favor. Real feedback comes from strangers who have no reason to be nice to you.
Ignoring bad feedback: You heard "this is confusing" and convinced yourself users just need time to learn. Sometimes they do. Usually they don't.
Polishing the wrong thing: You spent two weeks perfecting the design of a feature that might not matter. Validation matters more than beauty in an MVP.
Waiting too long to ship: You're "almost ready." You're always almost ready. There will never be a perfect time. Ship when you can learn something true.
The Psychological Shift
Building an MVP requires a mental shift. You have to stop thinking like you're building a complete product and start thinking like you're building a test.
A test is biased toward learning fast over learning perfectly. It's okay if it's rough. It's okay if it's slow. It's okay if it's incomplete. What's not okay is learning nothing.
The founders who win are the ones who can ship something imperfect, learn from it quickly, and improve. Not the ones who build perfectly alone and hope people love it.
Perfectionism feels safer. "If we ship when it's perfect, we can't fail." But that's not true. Perfect is often the enemy of learned. You can perfectly build something nobody wants. You can imperfectly build something the world needs.
Your MVP is the fastest path from "I have an idea" to "I know if this idea is real." Everything between those two points is waste.
Build small. Ship fast. Listen hard. Iterate relentlessly. That's the MVP mindset. That's how ideas become products.
The secret isn't building something perfect. It's building something real enough to teach you what perfect actually means to your customers.
If your MVP is a real website plus a clear value prop and a way to capture intent, Arepa can ship that end-to-end in minutes so your first week is spent talking to users, not wrestling with a stack.