The Biggest Misunderstanding in Software Scoping
Ask three companies what an MVP is and you will get three answers: the minimum feature set, the smallest demo, the version you can show investors. All of those miss the point. An MVP is not a smaller product; it is a smaller question. It is the smallest build that answers the one commercial question you cannot answer any other way — usually "will people use this and pay for it?" Confusing that with "a cheap version of the full thing" is how projects die, and it is the most common scoping error we see at Mwenaro Labs.
This guide lays out the framework we use to decide where "good enough" ends and "build it properly" begins. It complements the custom software vs off-the-shelf decision and the fintech cost guide for money-movement products.
What an MVP Is (and Is Not)
An MVP has one job: to test a risky assumption with real users, as cheaply as possible. That means it can look embarrassing and still be correct. If your assumption is "people will order groceries through WhatsApp," the MVP is a shared spreadsheet and a phone number — not a mobile app. The rule of thumb: if you can test the risk without building software, build nothing. Only when the test itself requires software does a software MVP make sense.
An MVP is not a prototype, a demo, or a skinless full product. It is a real product that solves the core problem for a small set of users, with manual work allowed behind the scenes. Manually doing something your software will later automate is a feature, not a failure — it proves demand before you pay for the automation.
The Scoping Framework
We scope every build with three questions, in order:
Answer those honestly and the scope stops being a guessing game. It becomes a decision about which risk you are paying to retire.
When to Build an MVP
An MVP is the right call when you are entering an unproven market, testing a new product category, or raising a first round and need user evidence. It is also right whenever the cost of building the full thing is large relative to what you can afford to lose — which, for most startups in Kenya, is almost always. The custom software guide covers how to know whether you even need a build; if you do, the MVP question follows.
A good MVP builds an honest slice of the product: one customer segment, one flow, one payment method. It is not "all features but smaller"; it is "one feature, complete."
When a Full Product Is Justified
A full build is justified when the risks are not demand questions but delivery and reliability questions. Three signals point there:
The Hybrid We Most Often Recommend
The pattern that serves most clients is neither a pure MVP nor a full build: it is a scoped full slice. Pick the one segment and one flow that matters most, and build that slice to production quality — real infrastructure, real security, real operations — while explicitly deferring the other features. You get the validation and speed of an MVP with the reliability of a real product, and the deferred features are written down, not skipped.
This is how we scope most Mwenaro Labs engagements: the client's risk profile decides the slice, and nothing else is built until the slice earns its keep.
The Ask That Ends Bad Projects
Whenever a client says "we want an MVP," the answer that protects both of you is: "What is the riskiest assumption we are testing, and how will we know it is true?" If the room goes quiet, there is no MVP — there is just a smaller wishlist, and that is a different (and worse) conversation. If the answer is clear and specific, you have a project worth scoping properly.
From there, the decision of custom vs off-the-shelf — for the core slice or the full product — is the next fork in the road. And for a scoping conversation grounded in the actual market, the Labs team will push back on your scope the same way we do internally.