What is an MVP?

An MVP - Minimum Viable Product - is the smallest functional version of your product that delivers enough value for real users to use it, complain about it, and ideally pay for it. The phrase was coined by Frank Robinson in 2001 and popularized by Eric Ries in The Lean Startup. The point is not to ship something half-broken. The point is to ship the smallest thing that proves your core hypothesis.

Three words matter most: minimum (less than you think), viable (it has to work, not just exist), and product (real users, real workflow, not a slideshow).

Not a prototype. A prototype demonstrates an idea to investors. An MVP is used by paying customers.

Not a landing page. A landing page validates demand. An MVP validates that your solution actually works for the demand.

Not a beta. A beta is a polished product opened to early users. An MVP is an unpolished product opened to the most patient users you can find.

Not v1. v1 is the first version of a finished product. An MVP is the first version of an experiment.

Airbnb (2007): Two roommates rented out air mattresses in their San Francisco apartment to conference attendees. The MVP was a single-page website with three photos. They had to manually email each guest. It validated that strangers would pay to sleep in someone's living room.

Dropbox (2007): Drew Houston released a 3-minute demo video showing how Dropbox would work. The waitlist went from 5,000 to 75,000 overnight. The MVP was the video - not the product.

Zappos (1999): Nick Swinmurn took photos of shoes at local stores and listed them on a basic website. When someone bought a pair, he ran to the store, paid retail, and shipped them. The MVP proved people would buy shoes online before he ever held inventory.

Buffer (2010): A two-page landing site. Page one: "Schedule tweets in advance." Page two: a fake pricing page. When users clicked a plan, Joel Gascoigne saw the email signup and realized people would pay. He built the product after.

List every feature you can imagine. Now cut 80% of them. The 20% you keep is your MVP.

The cuts will hurt. You will feel the product is too small. That is the point. If you don't feel embarrassed by your MVP, you launched too late - that's the famous Reid Hoffman line, and it's true.

The features you must keep: the single workflow that delivers your core value. If you're building a project management tool, that's create a task → assign it → mark it done. Everything else (notifications, integrations, analytics, billing) waits until people actually use the core loop.

For a focused MVP with one workflow, 4–6 weeks is realistic with a senior full-stack developer. Anything beyond 8 weeks usually means scope crept in. Anything under 3 weeks usually means you cut viability, not just minimum.

At LaunchCraft Studio, MVPs ship in 4–6 weeks because the constraint is enforced from day one - fixed scope, fixed price, fixed timeline. The discipline isn't about speed for its own sake. It's about preserving founder runway and shipping something real before assumptions calcify.

Three honest paths:

$0–$2,000 (no-code): Webflow, Bubble, Glide, Softr. Fast, cheap, ceiling on customization. Good for content sites, simple marketplaces, internal tools.

$2,500–$10,000 (founder-led studio or senior contractor): Real code, your stack, full ownership. Faster than an agency, more accountable than a freelancer.

$30,000–$100,000 (agency): Multi-person team with PM, junior developers, and overhead. Most of the cost is structural, not output.

LaunchCraft Studio is in tier two - fixed-price MVPs from $800 - $20,000. See full pricing →

If you can't code yourself, the question becomes: who builds it, and how much do you trust them?

Start with a problem you can describe in one sentence. If you need three sentences, the problem isn't tight enough yet.

Sketch the core flow on paper. Not designs - flow. Login, action, outcome. Three boxes connected by arrows.

Get a written quote with fixed scope. Hourly billing punishes you for asking questions. Fixed scope forces the developer to think hard upfront.

Insist on weekly demos. Not status calls. Demos. If you can't see it working at the staging URL by week 2, something is wrong.

Own the code from day one. The repo lives in your GitHub account. The deploy lives in your hosting account. If your developer disappears, you don't lose the product.

Mistake 1: Building features for fictional users. Talk to 5 real users before writing a line of code. Their words become your spec.

Mistake 2: Skipping payments. Free MVPs validate use, not value. If you can't charge $1, you don't have a business.

Mistake 3: Polishing the wrong thing. Animations, dashboards, and admin tools don't ship the core workflow. Cut them.

Mistake 4: Hiring an agency. Agencies optimize for billable hours. MVPs optimize for ruthlessness. The two don't mix.

Mistake 5: Waiting for perfect. The day you ship is the day you start learning. Until then, you're guessing.