A minimum viable product, or MVP, is the smallest version of your software that lets real users complete the core action your product exists for — nothing more. The discipline is not in the word "minimum," it is in the word "viable": the product still has to work well enough that a real customer would use it and, ideally, pay for it. Most Nigerian founders we talk to get this wrong in one of two directions — they build too much before launch and run out of money before finding out if anyone wants it, or they build so little that the product cannot actually prove anything useful.
The One Question That Decides What Goes In
Before listing features, answer this: what is the single core action a user needs to complete for your product to have delivered value? For a booking platform, it is completing a booking. For an inventory tool, it is recording stock accurately. Everything that directly supports that one action belongs in the MVP. Everything else is a candidate to cut.
What Usually Belongs in an MVP
The core workflow, built well
Not every workflow — the one workflow your product exists for. Build it properly, with good UX, rather than building five mediocre workflows. A hotel booking MVP needs a smooth booking flow more than it needs a loyalty points system.
Basic user accounts and authentication
Users need to sign up, log in, and have their data persist. This is foundational infrastructure, not a "nice-to-have" feature, so it belongs even in a lean first version.
Payment collection, if revenue depends on it
If your business model depends on charging customers, payment has to work in the MVP — you cannot validate willingness to pay without actually asking people to pay. Paystack or Flutterwave integration for a Nigerian product is core infrastructure, not a later add-on.
Enough admin visibility to operate the business
You need to see what is happening in your own product — new signups, transactions, basic activity — even if that visibility is a simple dashboard rather than a polished analytics suite.
What Usually Should Be Cut From an MVP
Anything "nice to have" that does not touch the core action
Referral programs, gamification, advanced personalization, multi-language support — these are worth building once you have real usage data telling you they matter, not before you know if the core product works.
Admin features beyond what you need to operate
Advanced reporting, granular permission systems, and configurable settings are things your first 50 users will never touch. Build them when your team's actual operational pain justifies the investment.
Support for edge cases that have not happened yet
Multi-currency support, complex tax rules, or unusual user roles are worth deferring until you actually have a customer who needs them. Building for hypothetical edge cases before real ones appear is one of the most common ways MVP budgets balloon.
Native mobile apps, before a web app has proven the concept
A responsive web app or progressive web app validates a concept faster and cheaper than a native iOS and Android build. Save the native app investment for after you know the product works — see our guide on PWAs vs native apps for more on this trade-off.
How We Approach MVP Scoping at Harzotech
When we scope an MVP for a client — whether it was the early version of StayQuora before it became a full hotel management platform, or a first version of a client's custom system — we start by mapping the single core workflow and refuse to add anything that does not directly serve it. This keeps the initial build lean, launches faster, and gives you real usage data to decide what to build next, rather than guessing.
The MVP is not the final product — it is the fastest, cheapest way to find out if you are building the right thing before you invest heavily in scaling it. Every feature you add beyond the core workflow is a bet you have not yet earned the right to make.
A Practical Cut List Exercise
- List every feature you are considering for launch
- Mark which ones are required for a user to complete the core action
- Move everything else to a "version two" list
- Estimate cost and timeline for just the required list
- Only add back from version two if the required list leaves genuine gaps in usability, not preference
What Happens After Launch Matters as Much as the Cut List
An MVP is only useful if you actually use what it teaches you. The point of shipping a lean first version is to watch real users interact with it and let that behavior — not internal opinions or assumptions — decide what gets built next. If your first 50 users all struggle at the same step, that is a genuine signal to fix. If nobody asks for a feature you assumed was essential, that is a signal too, and it is one that saved you the cost of building something nobody needed.
This is also where founders need discipline in the other direction. It is tempting to keep adding "just one more feature" before launch because it feels safer than shipping something minimal. Resist this. A lean MVP that launches four weeks earlier gives you a month of real user feedback that a more feature-complete version, launched later, cannot replace no matter how polished it is.
If you are scoping an MVP and want a second opinion on what actually belongs in version one, start a project conversation with Harzotech — we will help you separate what is essential from what can wait.