Before Dropbox opened to the public, Drew Houston didn’t have a finished product to show anyone. File syncing that just works is a hard engineering problem, and the product was a long way from launch. So instead of trying to build an MVP in code, he recorded a three-minute screencast showing how the product would work, filled it with in-jokes for the Digg crowd and posted it. “Our beta waiting list went from 5,000 people to 75,000 people literally overnight,” Houston later recalled, as quoted by Eric Ries in TechCrunch.
That video was the minimum viable product. It didn’t sync a single file, but it answered the question Houston most needed answered: do enough people want this badly enough to sign up for it?
That is what an MVP is for. Founders often treat it as “version one of the app, with fewer features,” then spend six months and most of their seed money building it. Doing it without wasting money starts with flipping that around. The goal is to test your riskiest assumption as cheaply and quickly as you can, and code is often the most expensive way to do it.
What an MVP is, and what it isn’t
Eric Ries, who popularized the term in The Lean Startup, defines the MVP as the version of a product that lets a team collect the most validated learning about customers with the least effort. Three words in that definition do the work: learning, validated and least.
An MVP isn’t a cheap or buggy product. It isn’t a demo for investors. And it isn’t necessarily software. It’s an experiment, and like any experiment it needs a hypothesis before it starts. If you can’t write down what you expect to learn and what result would prove you wrong, you aren’t building an MVP. You’re just building.
Before you build an MVP, find the riskiest assumption
Every startup idea rests on a stack of assumptions. Some are about customers (does this problem actually hurt?), some about value (will they pay, and how much?), some about growth (can we reach them affordably?) and some about feasibility (can we build it?).
Most first-time founders test feasibility first, because it’s what engineers know how to do. That’s usually backwards. Plenty of startups manage to build exactly what they set out to build and still fail, because not enough people wanted it. If the demand assumption is the shakiest one, test it before you write a line of production code.
A practical scoping exercise:
- Write down every assumption your business depends on.
- Rate each one on two scales: how uncertain you are, and how badly the business breaks if you’re wrong.
- Pick the single assumption that scores highest on both. That’s what your MVP must test.
- Define success in numbers before you start, for example “at least 30 of 200 visitors join the waitlist” or “five paying customers in four weeks.”
- Choose the cheapest experiment that could produce that number.
Step five is where the money gets saved.
Four MVP types that cost less than you think
The explainer or landing page
Dropbox is the classic case. A video or landing page describes the product as if it exists and asks for a concrete action: an email, a pre-order, a calendar booking. It tests demand and messaging for a few hundred dollars. The limitation is that signups are cheap, so treat them as a weak signal unless people are giving you something of value, like money or time.
The Wizard of Oz MVP
Here the customer sees what looks like a working product, but humans do the work behind the curtain. Zappos began this way in 1999. Founder Nick Swinmurn went to a shoe store in Sunnyvale, California, and offered to photograph its shoes and post them online. If anyone ordered a pair, he’d buy it from the store at full price and ship it, Fortune reported. There was no inventory, no warehouse and no logistics system. Orders came in, which proved people would buy shoes online. Amazon bought Zappos for $1.2 billion in 2009.
The Wizard of Oz approach is especially useful for AI products today. Before you build an automated pipeline, have a person do the task manually and see whether customers value the output.
The concierge MVP
A concierge MVP is similar, except the customer knows a human is helping. Food on the Table, an Austin startup that helped families plan meals and grocery lists, is often cited as the textbook concierge MVP. It started by serving early customers in person. The founders met them face to face, then moved to phone calls and emailed recipes and grocery lists. According to co-founder Manuel Rosso’s conference presentation, the team followed a simple rule: learn first, code last.
Concierge work doesn’t scale, and that’s the point. You learn exactly what customers value before you commit any of it to software.
The manual-hustle MVP
Sometimes the product exists but isn’t working, and the fix is something founders do by hand. Airbnb, which started in 2007 when Brian Chesky and Joe Gebbia rented air mattresses in their San Francisco apartment during a design conference, was stuck at about $200 a week in revenue in 2009. While they were in Y Combinator, the founders realized their New York listings had poor photos. So they rented a camera, flew to New York and photographed the listings themselves. Within a week revenue doubled to $400 a week, Gebbia recounted to First Round Review. Paul Graham later built a famous essay around this kind of work, titled “Do Things That Don’t Scale.”
In that 2013 essay, Graham also describes how Stripe’s Collison brothers signed up early users. Rather than sending a link, they would ask for the person’s laptop and set up the account on the spot. Unglamorous work like that is often the fastest route to finding out what users actually need.
No-code and AI tools: when they help
When you do need working software, you can now get surprisingly far without a full engineering team.
- Website and landing-page builders like Webflow, Carrd or Framer are enough for demand tests.
- Database-backed app builders such as Bubble, Glide and Softr can handle real users and payments. Bubble, for example, has a free tier for building and paid plans that start at US$59 a month, billed annually.
- Automation tools like Zapier and Make can connect forms, spreadsheets, email and payments into a working back office.
- AI app builders such as Lovable and Bolt can generate working front ends and simple back ends from a written prompt.
The catch: these tools make building cheap, which makes it tempting to build too much. A no-code app with 30 screens is still a six-month project. Use them to test one assumption, then stop. And plan for a rewrite if the idea works, especially in regulated areas like health or finance, where Canadian privacy laws and security reviews will catch up with you.
Metrics to watch while the MVP runs
Pick a small number of metrics tied directly to your hypothesis. Vanity metrics like page views, total signups and social likes feel good and tell you very little.
- Conversion to a costly action. What share of visitors pay, pre-order, book a call or hand over real data?
- Activation. What share of signups reach the moment where the product delivers value?
- Retention. Do people come back in week two, week four, week eight? A flattening retention curve, rather than one that falls to zero, is the clearest early sign of product-market fit.
- Willingness to pay. Ask for money early, even if it’s a small deposit. A “yes” with a credit card is worth a hundred “I’d use that.”
- The Sean Ellis test. Ask active users how they’d feel if they could no longer use the product. If 40 per cent or more say “very disappointed,” you’re probably on to something. Superhuman scored 22 per cent when it first ran the survey in 2017 and pushed that to 58 per cent within three quarters, according to First Round Review.
Talk to users as well as measuring them. Five honest interviews often explain a number that a dashboard can only show.
When to stop, pivot or push on
Set the stopping rule before you start, when you’re still objective. Write down three things: the success threshold, the time budget (four to eight weeks is common) and the money budget.
When the experiment ends, you’ll face one of three outcomes:
- Clear pass. Customers hit or beat the threshold. Move to the next riskiest assumption and invest a bit more.
- Clear fail. Almost no one takes the costly action. Don’t add features to rescue it. Go back to your customer interviews and either change the customer, the problem or the solution. That’s a pivot.
- Ambiguous middle. Some interest, nothing decisive. This is the most dangerous result, because it lets you keep spending. Narrow the experiment, for example by targeting one customer segment, and rerun it with a firmer threshold.
Be wary of the sunk-cost trap. The money you’ve spent on an MVP is gone whatever you decide next. The only question is whether the next dollar is more likely to produce learning than the last one.
A lean MVP checklist for Canadian founders
- Write the hypothesis and the pass/fail number before you build anything.
- Choose the cheapest test first: landing page, then concierge, then Wizard of Oz, and only then code.
- Cap spend and time up front, and stick to the cap.
- Charge money as early as you can.
- Keep notes on technical experiments. If you later build genuinely uncertain technology, those records can support an SR&ED tax credit claim.
- Look at non-dilutive help like NRC IRAP before raising money to build version two.
The founders behind Dropbox, Zappos and Airbnb didn’t win because their first versions were polished. They won because each of them found a cheap way to learn the one thing they most needed to know, and then acted on the answer. You can do the same with a few weeks and a few hundred dollars, as long as you’re willing to let the result change your plans.
Sources and further reading
- TechCrunch (Eric Ries): Dropbox’s minimum viable product
- Fortune: Nick Swinmurn, Zappos’ silent founder
- First Round Review: How design thinking transformed Airbnb
- Wikipedia: Airbnb
- Paul Graham: Do Things That Don’t Scale
- Manuel Rosso: Concierge MVP at Food on the Table
- First Round Review: How Superhuman built an engine to find product-market fit
- Bubble: Pricing
