Scoping an MVP That Tests Your Riskiest Assumption (Not Just the Easiest Feature to Build)

If you’re about to build your first (or next) startup, the most expensive mistake you can make isn’t picking the wrong tech stack or hiring too fast. It’s building an MVP that tests nothing critical about whether your business can actually work. Learning how to scope an MVP to test your riskiest assumption — rather than just your easiest feature — is the difference between a focused 60-day sprint and a 14-month detour that ends with a pivot or a shutdown.

Most founders call their first version an MVP. But what they’re actually shipping is an MVF: a Minimum Viable Feature. It looks like a product. It has a login screen, a dashboard, maybe some CRUD operations. What it doesn’t have is a direct line to the assumption that, if wrong, would make the entire business unworkable. I’ve seen this pattern over and over — including in my own work — and the research backs it up: CB Insights (2023) reports that 42% of startup failures come from no market need, a finding corroborated by First Round Capital’s startup failure analysis. That’s not a building problem. That’s a scoping problem.

This post gives you a risk-ranking exercise you can run in one sitting — plan for 90–180 minutes your first time — before you write a single line of code or sign a single contractor invoice. Two worked examples (a B2B SaaS and a marketplace) show exactly how it plays out, plus a third example for a solo founder building a consumer product.

Why Most MVPs Test the Wrong Thing

Here’s how the typical MVP scoping conversation goes: “What’s the smallest version we can ship?” The team lists features, cuts the nice-to-haves, and calls the rest the MVP. The problem is that “smallest version” optimizes for speed-to-launch, not for learning. You end up testing whether you can build the thing, not whether anyone will pay for it or whether the unit economics work.

A sharper framework — the Riskiest Assumption Test (RAT), a term popularized by Alberto Savoia in his pretotyping work and refined in Ash Maurya’s Lean Canvas methodology — flips the logic: instead of “what’s the smallest product we can build?” you ask “what’s the fastest way to disprove the assumption that would kill us?” The RAT doesn’t care if your test looks like a product. It cares whether it generates a clear signal on a binary question.

The distinction matters financially. An MVF might cost $15,000–$40,000 in contractor hours and 3–4 months of your time before you learn whether demand exists. A well-designed RAT experiment often costs under $1,000 and takes 1–2 weeks. If the assumption fails, you’ve saved everything downstream. If it holds, you build with confidence. Before you start scoping, it also pays to read about the ways friend feedback quietly distorts your customer validation — because a biased signal is almost worse than no signal at all.

The Risk-Ranking Exercise (Do This Before You Scope Anything)

Set a timer — plan for 90 minutes, up to 3 hours your first time through. You’re going to produce a ranked list of every assumption your business depends on, scored by two dimensions:

• Likelihood of being wrong — How confident are you, really, in this assumption? (1 = very confident, 5 = no real evidence)
• Cost of being wrong — If this assumption is false, how much of your plan collapses? (1 = recoverable pivot, 5 = entire business model fails)

Multiply the two scores to get a Risk Score (max 25). The top three items on that ranked list become the design brief for your MVP. Not features — hypotheses.

Step 1: List Every Assumption (15 minutes)

Be ruthless. Write down everything your business plan assumes to be true. A typical B2B SaaS has 15–25 assumptions if you dig honestly. Organize them into two categories:

• Market risk assumptions: Does the problem exist at scale? Are people aware of the problem? Would they pay to solve it? Is there switching cost from the current solution? Do they have budget authority to buy?
• Technical risk assumptions: Can you build this at the price point required? Will the core technical approach work? Can you achieve the performance benchmarks needed for the use case?

For most non-deep-tech startups in 2026, technical risk is secondary. The internet works, APIs exist, AI has dramatically reduced build cost. Market risk kills more companies than technical risk by a wide margin. Score accordingly.

Step 2: Score Every Assumption (30 minutes)

Fill out a table like this for each assumption. Two founders doing this independently, then comparing, is even better — the gaps in your scores reveal where your priors are misaligned.

Calibration guide before you score: Score 1 = you have talked to 10+ customers who named this exact problem unprompted. Score 2 = you have 3–5 conversations that confirmed it. Score 3 = you have anecdotal evidence but nothing systematic. Score 4 = you believe it based on market research you read, not conversations. Score 5 = this is an assumption you have never tested and no one has challenged. Apply this same anchoring to both axes.

Step 3: Design One Experiment Per Top-3 Assumption (30 minutes)

Each experiment must fit within a total budget of $5,000 and a 60-day window — if it cannot, redesign the test. For each of your top three Risk Score items, define the cheapest, fastest test that could generate a clear yes/no signal. The test doesn’t have to be digital. It doesn’t have to be automated. It just has to be honest.

Notice what’s not in that table: a working product. You’re spending under $500 and 60 days to answer the three questions that, if they come back negative, would mean you’ve saved yourself 6+ months and potentially $30,000–$80,000 in build costs. If your assumption is specifically about willingness to pay rather than just interest, a pre-sell page is a cleaner test than a waitlist — here is how to run one and collect real revenue before you build.

Step 4: Set a Kill Switch (15 minutes)

Before you run any experiment, write down the number that means “we stop.” This is harder than it sounds. Founders are optimists by nature — we rationalize weak signals. The kill switch forces the decision in advance, before you’re emotionally invested in the result. Write it down. Share it with your co-founder or an advisor. Make it a commitment, not a guideline.

A kill switch has to be a single falsifiable sentence. Here is the format: “If [specific measurable outcome], we stop and reassess before spending another dollar.” Four examples:

• If fewer than 10 of 20 calls confirm discretionary software budget, we stop outbound and redesign the offer.
• If the landing page converts below 8% after 200 visitors, we do not build the waitlist sequence.
• If zero content-sourced trials in 45 days, we reassess the content channel entirely.
• If no one books a second demo, we assume the positioning is wrong, not the product.

Worked Example 1: B2B SaaS (Compliance Workflow Tool)

A founder building a compliance checklist SaaS targeting HR managers at companies with 50–200 employees had a working prototype after two months of nights and weekends. It was clean, functional, and had exactly zero paying users.

When we ran the risk-ranking exercise retroactively, her #1 assumption — Risk Score 20 — was that HR managers at this company size had budget authority for software purchases under $400/month. Her #2 assumption — Risk Score 16 — was that compliance anxiety was painful enough to trigger active tool-seeking behavior (rather than passive “we should fix this someday” status).

Her kill switch, had she set one in advance, would have looked like this: “If fewer than 3 of 20 calls confirm budget authority at the manager level without VP approval, we stop.” She would have stopped at call 6. Both assumptions were wrong: the $400/month purchase required a VP sign-off and a 6-week procurement cycle, and most HR managers were aware of their compliance gaps but waiting for something to go wrong first — a reactive trigger, not a proactive one.

She pivoted to target companies with 200–500 employees, increased price to $1,200/month where procurement cycles were standardized and faster, and repositioned around post-incident remediation rather than proactive compliance. The reframe took 30 days. The original prototype still worked. But she lost two months because she built before she scored.

Worked Example 2: Marketplace (Skilled Trades Labor)

A marketplace connecting independent electricians and plumbers with property managers faces a classic two-sided cold-start problem — but that’s actually not the riskiest assumption. When this founding team ran the exercise, their top three were:

1. Property managers will pay a marketplace fee (vs. calling a contractor directly after the first job) — Risk Score 20
2. Skilled tradespeople will accept job offers from an app rather than relying on their existing referral network — Risk Score 16
3. There’s enough supply density in a single metro to fulfill jobs within 4 hours — Risk Score 14

Kill switches, set in advance: “If fewer than 4 of 15 property managers agree to a fee after the free pilot, we do not launch the paid tier.” And: “If fewer than 10 tradespeople respond to fake job listings in 2 weeks, we reassess supply acquisition.”

They designed three experiments without building the marketplace: (1) recruited 15 property managers and offered to find a plumber for them, manually, for free — to test willingness to engage; (2) posted fake job listings in three Facebook trade groups and tracked response rates and quality of replies; (3) mapped licensed electrician density using state licensing databases for their target metro.

Results: property managers loved the service when it was free but pushed back hard on a 12% fee (“I’ll just call back the guy who came last time”). The first kill switch triggered — only 2 of 15 agreed to the fee. Tradespeople responded enthusiastically to app-based job offers. Supply density was fine. The business model assumption — not the supply or demand existence — was the failure point. They renegotiated their fee model to a flat monthly subscription for property managers ($89/month) and tested re-conversion. That version worked.

Total experiment cost: $0 in software, ~80 hours of founder time. Total time to the insight: 3 weeks. This is what it looks like when you validate before you build instead of building before you validate.

Worked Example 3: Solo Founder, Consumer Subscription App

Not every founder has a co-founder, a B2B target customer, or an enterprise sales motion. Consider a solo founder building a habit-tracking app for remote workers — a consumer subscription at $8/month. The two riskiest assumptions: (1) remote workers will pay monthly for an accountability tool when free alternatives exist (Risk Score 20); (2) the founder can acquire users at under $3 CAC through organic channels given the competitive App Store environment (Risk Score 16).

Kill switch for assumption 1: “If fewer than 15 of 50 survey respondents say they would pay $8/month and can name a time in the last year they paid for a similar habit or productivity tool, we stop.” Kill switch for assumption 2: “If a 30-day organic content push produces fewer than 100 email signups from non-friends, we do not build the iOS app.”

The experiment: a no-code landing page (Carrd, $19/year) plus a 30-day newsletter on habit science published on Substack and cross-posted on LinkedIn. No app. No code. After 30 days: 214 subscribers, 31 respondents confirmed willingness to pay via a survey with named comparable purchases. Both assumptions held. The founder spent $200 total and 40 hours before writing a line of Swift. The consumer context doesn’t change the framework — it just changes the experiment design and the channels you use to reach people.

The $5K / 60-Day Constraint — And Why It’s a Feature, Not a Bug

The budget and timeline constraints in this framework aren’t arbitrary. They’re designed to force intellectual honesty. When you have $50,000 and six months, it’s easy to rationalize “let’s just build it and see.” When you have $5,000 and 60 days, you have to be surgical about what question you’re actually answering.

Founder time is money — and it’s often the most expensive money in the building phase. At any reasonable opportunity cost (even $50/hour), 60 days of two co-founders working half-time is $24,000–$48,000 in implicit labor cost, before a dollar of contractor spend. The experiments described above cost a fraction of that and generate better signal than a shipped product would in the same timeframe.

The constraint also creates a forcing function for the next step: once your top three assumptions survive testing, you’ve earned the right to build. And because you’ve done the hard thinking, you know exactly what to build — the smallest artifact that converts a validated assumption into a retained customer. That’s where first traction becomes engineered rather than accidental. Read more about how getting first customers is an engineered outcome, not a discovery.

Common Objections — and Honest Answers

“But what if a competitor launches while we’re testing?” If your competitive advantage is so thin that a 60-day delay would invalidate it, that’s actually important information about the durability of your moat. Most B2B markets and marketplaces don’t move that fast. The risk of launching a product nobody wants is higher than the risk of a competitor moving in 60 days.

“We’re building something technical — doesn’t technical risk matter?” Yes, but distinguish between technical feasibility risk (can this be built at all?) and technical execution risk (will we build it on time?). Feasibility risk should be in your risk table and scored honestly. If your #1 assumption is technical — a novel ML model that has to hit a performance threshold — then your first experiment is a technical spike, not a customer conversation. Most non-deep-tech startups don’t have a #1 technical risk. Be honest about which bucket you’re in.

“The exercise sounds like it takes longer than 90 minutes.” Plan for 90–180 minutes your first time through. Do it anyway. The alternative is months of misdirected effort. Once you’ve done it once, the next scoping exercise takes 60 minutes.

FAQ: Scoping an MVP Around Your Riskiest Assumption

How is the Riskiest Assumption Test different from just doing customer discovery?

Customer discovery is one tool; the RAT framework is the decision-making structure that tells you which questions to bring into customer discovery and what signal would change your plan. Without a ranked assumption list and a pre-committed kill switch, customer discovery interviews tend to confirm what founders already believe — especially because most founders unconsciously screen for positive signals. The risk-ranking exercise forces you to name the assumptions you’re most afraid are wrong, then design tests specifically to break them.

What counts as “good enough” evidence before starting to build?

A useful threshold: three of your top-five assumptions should have at least one piece of external evidence (a real conversation, a paying pre-order, a measured click-through on a landing page) before you start writing production code or signing contractor agreements. “External” is the key word — evidence from inside your own head doesn’t count. Pre-orders or letters of intent are the gold standard for market risk; technical spikes or proof-of-concept demos are the gold standard for technical risk.

Can this framework work for solo founders without a co-founder to pressure-test assumptions?

Yes, but you need a substitute for the disagreement that co-founders naturally generate. Find one advisor or operator peer who has built in your space and give them your assumption table before you score it — ask them to score it independently, then compare. The divergences are your highest-value conversations. If you don’t have access to that person yet, a founder community, accelerator office hours, or even a well-framed cold email to a domain expert can fill the role. The goal is one external perspective before you commit to your top-three list.

How long should an MVP take to build?

Once you have validated your top three assumptions, an MVP should take no longer than 6–8 weeks to a testable artifact. If your build plan exceeds that, you have scoped a product — not an MVP. Apply the $5K / 60-day constraint to the build phase too: if the MVP cannot be built within those guardrails, cut scope until it can. An MVP that takes 4 months to build is an MVF with extra steps.

What is the difference between an MVP and a prototype?

A prototype tests whether you can build a thing and how it should work. An MVP tests whether people will use and pay for the thing you built. A prototype is typically internal; an MVP is put in front of real users with real stakes. In this framework, your RAT experiments are often closer to prototypes — they are designed to generate a signal, not retain customers. The MVP comes after the experiments pass. Do not skip from prototype straight to full product build.

About Cole Merritt

Cole Merritt is a startup operator and advisor who has worked with early-stage B2B and marketplace founders across the validation and pre-seed phases. He writes for Bright Curios on product strategy, market validation, and the financial decisions founders face before they build. His work focuses on the gap between “idea worth testing” and “product worth building” — and why most founders rush through it. Learn more about the Bright Curios team on the About page.

The Next Step: Run the Exercise This Week

The best time to learn how to scope an MVP to test your riskiest assumption is before you’ve sunk weeks into a product nobody asked for. Block 90–180 minutes this week, open a spreadsheet, and list every assumption your business depends on. Score each one. Find your top three. Design the cheapest test that could disprove each of them.

If all three tests come back positive, you have a green light to build — and you’ll build faster and more confidently because you know what you’re building toward. If one or two come back negative, you’ve just saved yourself months and thousands of dollars. Either outcome is a win. The only losing move is skipping the exercise and calling it an MVP when it’s really just a wish list in a GitHub repo.

This post is for general informational and educational purposes only. It does not constitute professional legal, financial, or business advice. Every startup’s circumstances are different — consult qualified advisors before making significant financial or strategic commitments.