How to Scope an MVP Without the Guesswork

Three MVP Validation Examples That Changed How I Scope Products

A Nottingham-based founder came to me last month with wireframes, a dense feature list, and a development quote from three different agencies. The estimates ranged from £15,000 to £80,000. He wanted me to tell him which one to pick.

I asked him a different question: “Have you shown this to anyone who would pay for it?”

He hadn't. He had spent three months designing screens for a problem he assumed existed, based on his own experience and a few conversations with mates. This is the pattern I see most often – people validate their idea by building it, then discover nobody wants what they've made.

Proper validation happens before you write code or hire developers. It's about finding out if you're wrong, as cheaply and quickly as possible.

Here are three real examples of how validation worked in practice, what they taught me about scoping, and why the ones that felt disappointing at the time saved the most money.

Case 1: The Health App That Failed in Four Days

A few years ago, I worked with a consultant who wanted to build a platform connecting patients with specialist health services. She had deep domain expertise, a clear problem statement, and a vision for a two-sided marketplace.

We could have spent three months building a working platform. Instead, we spent four days validating the core assumption: would patients use a platform like this to find services, or would they just ask their GP?

We created a single landing page explaining the service, a fake sign-up form, and ran targeted ads to people searching for the specific health services she wanted to list. The page looked real. The value proposition was clear. We spent £200 on ads over 96 hours.

Result: 1,400 page views, 11 email sign-ups, zero people who completed the “tell us what you need” form that would have indicated real intent.

She was gutted. I was relieved.

That £200 and four days of work saved her £30,000 and six months building something nobody would use. The real problem was that patients didn't behave the way she assumed they would. They wanted their GP to refer them, not a platform to choose from.

The lesson: if people won't give you their email address for free, they definitely won't give you their money later. Validate demand before you validate your solution.

Case 2: The Corporate AI Tool That Pivoted in Week Two

An internal innovation team at a mid-sized professional services firm wanted to build an AI assistant to help consultants write client proposals faster. They had already mapped out the features, discussed integration with their CRM, and estimated six months of development time.

I suggested we validate it differently: build a terrible version in two weeks using off-the-shelf tools, then put it in front of ten consultants and watch them try to use it.

We used a no-code form builder, a simple prompt library, and connected it to ChatGPT via API. It was clunky. It looked like a prototype because it was a prototype. We told the consultants exactly that – this is rough, we want to see if the concept works before we build it properly.

They used it for a week. Then we interviewed them.

The insight: they didn't need help writing proposals. They needed help finding the right case studies and past project examples to include in proposals. The writing part was easy. The research and digging through old files was the pain point.

We pivoted the concept in week two. The final product ended up being a searchable knowledge base with AI-powered recommendations, not a proposal writing assistant. It took four months to build instead of six, cost about 40% less, and got used because we had validated the real problem.

The lesson: people will tell you what they think they need. Watching them work shows you what they need. Validation isn't a survey - it's observation.

Case 3: The SaaS Tool That Worked (and Why That Was Harder)

Not all validation ends with a pivot or a kill decision. Sometimes the idea works, and that brings its own challenges.

I worked with a founder building a scheduling tool for freelance tutors. He had a landing page, an email list of 200 people from his own network, and a rough Figma prototype.

We sent the prototype to 30 tutors and asked them to walk through booking a session with a fake student. Twenty-six of them completed it. Fifteen said they would pay £15–£25 per month for it. Four asked when it would be ready.

The hard part: now you have to build it, and the expectations are set. Those 26 tutors are waiting. They remember what you showed them. If you spend six months building features they didn't ask for, or if the final product is worse than the prototype, you've burned your early adopters.

This is where most founders get scope wrong. They take validated demand as permission to build everything they originally imagined, rather than building only what was validated.

We scoped his MVP to three features: calendar sync, booking links, and payment processing. No reporting dashboard, no multi-user accounts, no integrations with other tools. Just the workflow that 26 people had tested and said they would pay for.

He shipped it in eight weeks. Sixteen of the original 26 converted to paying customers in month one. That revenue funded the next features, which were chosen based on what those 16 customers asked for, not what he had assumed they would need.

The lesson: validation tells you what to build first, not what to build eventually. Treat it as a scope constraint, not a green light to build everything.

What Makes a Good MVP Validation Plan

These examples share a pattern. They all started with an assumption about user behaviour, tested that assumption as cheaply as possible, and treated 'this didn't work' as useful data rather than failure.

A good validation plan has three parts:

1. The riskiest assumption written down clearly – not “will people like this?” but “will patients choose their own specialist without a GP referral?” or “do consultants struggle to write proposals or find information?”.
2. A test that produces evidence, not opinions – landing pages with real ad spend, prototypes people try to use for real tasks, not focus groups or surveys asking “Would you use this?”.
3. A decision threshold agreed in advance – if fewer than X people sign up, we kill it; if users can't complete the task in Y minutes, we rethink it; no moving goalposts after you get the data

Validation fails when founders treat it as a box-ticking exercise. They run a test, get weak signals, then build the thing anyway because they've already emotionally committed to the idea.

How to Know If Your Validation Worked

People ask me this a lot: “How do I know if I've validated enough?”

There's no universal threshold, but here's the test I use: if the validation process hasn't changed your original plan in some meaningful way, you probably haven’t validated properly.

Real validation surfaces uncomfortable truths. It narrows your scope, shifts your positioning, or kills features you were excited about. If you finish validation and your plan looks identical to where you started, you likely just ran a confirmation exercise.

The health app founder didn't want to hear that patients wouldn't use her platform. The corporate team didn't expect to pivot from writing to research. The tutor tool founder had to cut 70% of his original feature list.

Validation makes your plan smaller, sharper, and more likely to work.

If you have an MVP idea and you're not sure what to validate first, I’ve created an MVP Cost Clarity toolkit on my page. Use the following link to download your copy for free:

MVP Cost Clarity Toolkit

If you want to identify your riskiest assumptions, design a validation test, and figure out what you should build – book a call with me using the following link:

Book a slot on my calendar.