From Idea to MVP: A Strategic Framework for Validation
by Julius, Director & Strategic Development Partner
Most founders arrive with a clear vision and a long feature list. The temptation is to start building straight away.
The problem is that every idea rests on assumptions: that a particular group of people has a particular problem, that they'll change their behaviour to solve it, and that they'll pay for the solution. Building before you've tested those assumptions is the most expensive way to find out which ones are wrong.
A minimum viable product (MVP) exists to test them. This is the framework we use to get from idea to MVP with as little wasted effort as possible.
Step 1: Write down what has to be true
Start by listing the assumptions your idea depends on. Be specific. "People want this" isn't testable. "Immigration applicants will pay upfront for a self-service document pack instead of a consultant's time" is.
Group them into three kinds:
- Problem assumptions. Who has the problem, and how painful is it?
- Solution assumptions. Will your approach solve it better than what they do today?
- Business assumptions. Will they pay, how much, and can you reach them affordably?
Step 2: Rank them by risk
Not every assumption deserves the same attention. For each one, ask two questions: how confident are we, and what happens if we're wrong?
The assumptions that are both uncertain and critical go to the top of the list. Those are the ones your MVP needs to test first. Everything else can wait.
This is also where we identify risks during our own discovery phase, alongside a market and competitor analysis. Understanding what already exists tells you which assumptions others have already tested for you.
Step 3: Define success before you build
Decide what result would convince you that an assumption holds, and what result would tell you to change course. Write it down before launch, while you're still objective.
Good success metrics are tied to behaviour, not opinions. Sign-ups, completed journeys, repeat use and payments are far more reliable than people saying they like the idea.
Step 4: Scope the smallest thing that tests the riskiest assumption
Now, and only now, decide what to build.
Go back to your feature list and ask of each item: does this help us test one of our top assumptions? If not, it goes on the roadmap for later. The result is usually a much shorter list than you started with, and a product you can launch in weeks rather than months.
Sometimes the right MVP isn't software at all. A landing page, a manual service delivered behind the scenes, or a simple prototype can test demand before you invest in a full build.
Step 5: Build the business model into the MVP
An MVP that only tests whether people will use something free can leave your most important question unanswered.
When we worked with Status Correction Africa, one of the pivots we recommended during discovery was taking payment upfront through Paystack. That did two things at once: it filtered casual inquiries from serious applicants, and it tested the business model from day one rather than leaving it for later.
Think about which parts of your business model you can build in early, whether that's pricing, onboarding or how customers find you.
Step 6: Build in short cycles and keep watching
Once development starts, work in short sprints and review working software often. We show clients progress in a demo every week. Frequent reviews mean that when something you learn changes the plan, you can adjust while the change is still cheap.
Step 7: Launch, measure and decide
Launch to real users, measure against the success metrics you set in step 3, and make a clear decision: continue, adjust or stop.
Launch isn't the end of validation. It's the point where you finally get real data. The most useful work often happens in the months afterwards, as feedback comes in and the roadmap is reshaped around what users actually do.
Common mistakes to avoid
- Building everything at once. A long feature list delays launch and makes it harder to see what's working.
- Mistaking compliments for validation. Friends and early supporters are kind. Behaviour is honest.
- Skipping the business model. Usage without a path to revenue is only half an answer.
- Treating the MVP as throwaway. Cutting scope is healthy. Cutting quality in the parts you keep creates problems that are costly to unwind as you grow.
- Setting no success criteria. Without a target, every result looks encouraging.
Frequently Asked Questions
How long should it take to build an MVP?
It depends on what you need to test. A tightly scoped MVP can often launch in weeks. We start every project with a discovery phase of one to two weeks so that the scope and timeline are based on a clear understanding of your goals.
How is an MVP different from a prototype?
A prototype shows how something could work and is often used internally or with a handful of testers. An MVP is a working product that real users can use, so it can test real behaviour, including whether they'll pay.
Should an MVP be built with no-code tools?
Sometimes. If your riskiest assumptions can be tested with no-code tools, that can be the fastest and cheapest route. If the value of your product lies in a complex workflow or integration, a custom build may be the only way to test it properly.
What happens after the MVP?
You use what you've learned to decide what to build next. We stay involved after launch to help plan the next stage as real-world feedback comes in. You can read more about how we work on our process page.
Have an idea you want to test?
If you're planning an MVP and want to find out what's possible before you commit your budget, let's talk. We'll challenge your assumptions before we write any code.