Building Your MVP — Build a Startup

By the end of this module, you'll understand the MVP spectrum (from landing pages to single-feature apps), know how to scope-cut ruthlessly, and be able to design a build-measure-learn loop for any startup idea.

The $12 billion product that started with a video

In 2007, Drew Houston kept forgetting his USB drive. He was a MIT graduate, a competent programmer, and constantly losing files between his laptop and his desktop. One day, stuck on a bus from Boston to New York with no USB drive and four hours to kill, he started writing code for a file-syncing tool.

But Houston didn't spend two years building Dropbox in silence. Instead, he made a 3-minute screencast. The video showed a demo of the product — files dragging into a folder and magically appearing on another computer. It looked real. It wasn't. Most of the functionality shown was smoke and mirrors, pieced together to demonstrate the concept.

He posted the video to Hacker News. The waitlist jumped from 5,000 to 75,000 people overnight. That video was Dropbox's MVP — and it validated the idea without shipping a single line of production code.

Dropbox went on to IPO at a $12 billion valuation in 2018.

3 minlength of Dropbox's MVP video

75Kwaitlist signups overnight

12BDropbox IPO valuation (2018)

What an MVP actually is (and isn't)

The term "Minimum Viable Product" was popularized by Eric Ries in The Lean Startup (2011), building on ideas from Steve Blank. It's the most misunderstood concept in startups.

An MVP is not a half-baked product with bugs everywhere. It's not version 1.0 with fewer features. It's the smallest thing you can build or do to test your riskiest assumption.

✗ What an MVP is

✗The smallest experiment that tests your biggest risk
✗Built to learn, not to impress
✗Can be a landing page, video, manual service, or simple prototype
✗Focuses on one core value proposition
✗Takes days or weeks, not months

✓ What an MVP is NOT

✓A buggy version of your final product
✓Built to ship to thousands of users
✓Always a working software application
✓Tries to include every feature you imagined
✓Takes 6 months of development

The key question to ask: "What is the riskiest assumption in my business, and what is the cheapest way to test it?"

💡Validation first, then MVP

If you've worked through the previous module on validation, you already know your riskiest assumptions. Your customer interviews identified the pain. Your TAM/SAM/SOM analysis confirmed the market exists. Now your MVP tests whether your **solution** actually solves the problem. The validation stack you built — interviews, landing page, concierge — was step one. The MVP is the next experiment in that stack.

For Dropbox, the riskiest assumption wasn't "can we build file sync?" (Houston was a strong engineer). It was "do enough people care about this problem to switch from USB drives and email attachments?" A video answered that question for the cost of a few hours of work.

🔑The MVP spectrum

MVPs exist on a spectrum from zero-code to functional product. A landing page is an MVP. A concierge service is an MVP. A spreadsheet that does what your app would do is an MVP. Your MVP should match your riskiest assumption, not your ambition.

The MVP spectrum: from zero code to working product

Not every MVP requires coding. Here are the most common types, ordered from simplest to most complex:

MVP type	Effort	Best for	Example
Landing page	1-2 days	Testing demand	Buffer's pricing page before the product existed
Explainer video	2-5 days	Showing a complex product concept	Dropbox's demo video
Concierge	1-2 weeks	Testing if the value proposition works	Food on the Table — manually planned meals for users one-by-one
Wizard of Oz	1-2 weeks	Testing the full experience with humans behind the scenes	Zappos — manual shoe purchasing and shipping
No-code prototype	1-3 weeks	Testing a workflow or marketplace	Early Groupon was a WordPress blog with PDF coupons emailed manually
Single-feature app	2-6 weeks	Testing core product functionality	Instagram launched with photo filters and sharing only — no stories, no reels, no DMs

🔒

Match the MVP Type

25 XP

For each startup scenario, classify the best MVP approach: **Categories: Landing Page, Explainer Video, Concierge, Wizard of Oz, No-Code Prototype, Single-Feature App** 1. You want to test if busy parents would pay for AI-generated bedtime stories customized to their child → ___ 2. You're building a complex supply chain tool and need to show how the dashboard works → ___ 3. You want to test if freelancers would pay for automated tax categorization — you can do it manually in a spreadsheet for now → ___ 4. You have a simple idea for a habit tracker and you can build a basic version in Bubble in two weeks → ___ _Hint: Match the MVP type to what you're testing. Demand? Use a landing page. Value delivery? Use concierge. Complex concept? Use a video._

No-code tools for building MVPs fast

You don't need to be a developer to build a functional MVP. Here are the tools that let non-technical founders ship in days:

Tool	What it does	Cost
Carrd	Single-page websites and landing pages	Free - $49/yr
Typedream / Framer	Multi-page websites with CMS	Free - $15/mo
Airtable	Database + forms + automations	Free - $20/mo
Zapier / Make	Connect tools and automate workflows	Free - $20/mo
Stripe	Accept payments	2.9% + 30c per transaction
Tally / Typeform	Beautiful forms and surveys	Free - $25/mo
Bubble	Full web applications without code	Free - $29/mo
Glide / Softr	Turn spreadsheets into apps	Free - $25/mo
Figma	Clickable prototypes	Free

⚠️The no-code trap

No-code tools are for validating — not for scaling. They'll break at ~1,000 active users, have limited customization, and get expensive as you grow. Use them to prove demand, then rebuild properly when you know what to build. Don't spend 6 months perfecting a no-code app.

There Are No Dumb Questions

"If my MVP is manual and doesn't scale, isn't that a waste of time?"

No — it's the most efficient use of your time. Paul Graham, co-founder of Y Combinator, literally advises startups to "do things that don't scale." Manual processes teach you exactly what your product needs to automate. Airbnb co-founders personally photographed apartments. Stripe founders manually installed their software on users' laptops. These "unscalable" actions built deep understanding of the customer.

"How do I know when my MVP is 'minimum' enough?"

If you're not embarrassed by your first version, you launched too late — that's often attributed to Reid Hoffman (LinkedIn co-founder), and it captures the spirit: your MVP should feel uncomfortably bare. Ask: "Can I remove one more feature and still test my core assumption?" If yes, remove it.

The art of scope cutting

The biggest mistake first-time founders make with MVPs is including too many features. Here's how to cut scope ruthlessly:

Step 1: List every feature you can imagine.

Step 2: For each feature, ask: "Does this test my core assumption?" If no, cut it.

Step 3: Of what's left, ask: "Can my first 10 users live without this for 2 weeks?" If yes, cut it.

Step 4: What remains is your MVP.

🔒

Cut This MVP Down to Size

50 XP

A founder wants to build a marketplace for freelance graphic designers. They've listed these features for their MVP: 1. Designer profiles with portfolios 2. Client job posting 3. In-app messaging 4. Payment processing with escrow 5. Review and rating system 6. AI-powered designer matching 7. Project management tools 8. Mobile app (iOS + Android) 9. Video call integration 10. Invoice generation Which 3-4 features would you keep for the MVP, and why? What's the core assumption being tested? _Hint: The core assumption is "will clients pay freelance designers through our platform?" What's the minimum needed to test that?_

Getting your first 10 users

Your first users won't come from Google ads or viral growth. They'll come from hustle. Here's how successful startups got their earliest adopters:

Go where they already are. Airbnb founders posted on Craigslist. If your customers hang out in a subreddit, a Slack community, or a Facebook group — go there. Don't spam. Provide value first, then mention your product.

Personal outreach. Email or DM 100 people individually. Not a mass blast — personal, specific messages that show you understand their problem. Expect a 10-20% response rate. That's 10-20 conversations from 100 messages.

Leverage your network. Ask friends and contacts: "Who do you know that has [problem]?" Don't ask them to use your product — ask them for introductions to people who fit your target customer profile.

Launch on Product Hunt or Hacker News. If your product is B2B or developer-focused, these communities can deliver hundreds of signups in a day. But only launch when you have something to show — you get one shot at a first impression.

Offer something free or discounted. Your first 10 users are doing you a favour by using an unfinished product. Give them lifetime free accounts, heavy discounts, or early-adopter perks. Their feedback is worth more than their revenue.

There Are No Dumb Questions

"What if nobody wants to use my MVP?"

That's data, not failure. If you can't get 10 people to try your product for free, you have one of three problems: (1) you're targeting the wrong audience, (2) your messaging doesn't communicate the value, or (3) the problem isn't painful enough. Go back to customer interviews.

"Should I charge from day one?"

It depends on what you're testing. If your assumption is "will people pay for this?", then yes — charge immediately. If your assumption is "does this solve the problem?", then free or discounted access gets you faster feedback. But don't stay free forever. Price is the ultimate validation.

The build-measure-learn loop

Eric Ries's core framework from The Lean Startup is a simple cycle:

The goal is to complete this loop as fast as possible. Every day you spend building without measuring is a day you might be building the wrong thing.

What to measure after launching your MVP:

Metric	What it tells you	Red flag
Activation rate	% of signups who complete the core action	Below 20%
Retention (Day 7)	% who come back after a week	Below 10%
NPS or qualitative feedback	Do they love it or tolerate it?	"It's nice" (lukewarm = death)
Willingness to pay	Would they pay? How much?	"I'd use it if it were free"
Referrals	Do they tell others unprompted?	Zero organic word-of-mouth

🔒

What's Wrong With This MVP Strategy?

25 XP

A founder says: "I'm going to spend 4 months building a polished app with 15 features, launch it on the App Store, run $10,000 in Facebook ads, and see what happens." List at least 3 things wrong with this approach. _Hint: Think about time, money, assumptions, and the build-measure-learn loop._

Iterating on feedback: what to listen to and what to ignore

Not all feedback is created equal. Here's how to filter:

✗ Listen to this

✗Patterns across multiple users
✗Behaviour (what they do, not say)
✗Feature requests tied to a workflow they're already doing
✗Complaints from your target customer segment
✗Data showing where users drop off

✓ Ignore this

✓One person's strong opinion
✓What people say they'd hypothetically do
✓Feature requests that don't match your core value
✓Feedback from people outside your target market
✓Requests for features your competitors have

The golden rule of iteration: Change one thing at a time. If you change the onboarding, the pricing, and the landing page simultaneously, you won't know which change caused the result.

🔒

Prioritise This Feedback

25 XP

Your MVP is a simple budgeting app. After 2 weeks with 30 beta users, you've received this feedback: - 18 users say the categorisation of expenses is confusing - 3 users want dark mode - 12 users stopped using it after day 3 - 1 user wrote a long email requesting investment tracking - 8 users say they love it but wish it synced with their bank Which feedback do you act on first, and why? _Hint: Look for patterns, focus on retention, and distinguish core value from nice-to-haves._

Back to the bus from Boston

Drew Houston didn't have a team, a VC check, or a launch plan. He had a frustration — forgetting his USB drive — and a 3-minute video that showed what a solution could look like. That video wasn't a product. It was a question: "Do enough people care about this problem?"

Seventy-five thousand people answered overnight. Houston didn't need to build Dropbox to discover the answer. He needed the smallest possible experiment — and the willingness to put it in front of real people. Your MVP doesn't need to be a video. It might be a spreadsheet, a manual service, or a landing page. The format doesn't matter. What matters is that you ship something, measure the response, and learn.

Key takeaways

An MVP is the smallest experiment that tests your riskiest assumption — not a crappy version of your product
You don't need code to build an MVP — landing pages, videos, manual services, and no-code tools all count
Scope cut ruthlessly — for each feature, ask "does this test my core assumption?" If not, cut it
Your first 10 users come from hustle, not ads — personal outreach, communities, and your network
The build-measure-learn loop is the engine of progress — complete it as fast as possible
Filter feedback by patterns, not individual opinions — and change one thing at a time

💡Next up: should you raise money?

Your MVP is live and you're learning from real users. The next question: do you need outside funding to grow, or should you bootstrap? In the next module, you'll learn about fundraising stages, valuation math, cap tables, and term sheets — and most importantly, when NOT to raise.

Knowledge Check

1.What was Dropbox's MVP, and why did it work?

2.What is the primary purpose of an MVP?

3.In the build-measure-learn loop, what should you do after measuring results from your MVP?

4.A founder can't get 10 people to try their free MVP. What is the most likely problem?