Most startup products are too big at launch. Not because founders are careless, but because every feature feels essential when you have been thinking about the idea for months. The result is a first version that takes too long, costs too much and still launches into silence.
A minimum viable product (MVP) is the smallest version of your product that can test whether people want it enough to use it, pay for it or come back to it. The skill is deciding what "smallest" means for your idea.
Start from the One Question You Need Answered
Every MVP exists to answer a question. Write yours down before anything is designed.
- Will drivers sign up and stay online in this city?
- Will venue owners pay monthly for booking software?
- Will customers book through an app rather than a phone call?
- Will this team actually use the dashboard every day?
If a feature does not help answer that question, it probably does not belong in the first version.
The Features That Usually Belong
- The core action. The one thing a user comes to do: book, order, list, request, pay.
- Just enough account management to sign in and see their own history.
- A way for you to see what is happening. A simple admin view of users and activity. Without it you are flying blind.
- A way for users to reach you. Often a WhatsApp or email link is enough at first.
The Features That Usually Wait
- Advanced settings and personalisation.
- Multiple user roles beyond the essential ones.
- Wallets, loyalty points and referral schemes.
- Detailed analytics dashboards.
- Support for every device, language and edge case on day one.
None of these are bad ideas. They are second-version ideas. Adding them later, once real users tell you which ones matter, is cheaper than building them blind.
Do Things That Do Not Scale
A good MVP often has a manual process hiding behind it. Approving accounts by hand, matching orders in a spreadsheet, sending some messages yourself. That is fine. Doing it manually teaches you the real rules, and you automate them once you understand them.
When we launched JaldiGO, operations work such as approving drivers and handling disputes ran through a console that people used every day. The software supported the team rather than replacing it, and the parts that proved repetitive became candidates for automation later.
How Long and How Much
An honest MVP for a typical business product often takes somewhere between a few weeks and a few months, depending on how many separate apps are involved (a customer app, a provider app and an admin panel are three products, not one) and how much has to happen in real time.
The biggest drivers of cost are:
- The number of user types. Each one needs its own screens and permissions.
- Real-time features. Live tracking, chat and instant notifications add real complexity.
- Payments. Taking money online brings security, refunds and reconciliation.
- Integrations with outside systems you do not control.
Cut any of these from the first version and both the timeline and the budget shrink noticeably.
Build It so It Can Grow
"Minimum" should not mean "throwaway". A well-built MVP has a sound data structure, proper security and code another developer can pick up. You should be able to keep building on it rather than starting again once it works.
Ask your development partner directly: if this succeeds, what do we keep and what do we rewrite? The answer should be "keep almost all of it".
Measure Before You Add
Before the launch, decide what success looks like. Sign-ups per week, bookings completed, users returning after seven days, revenue per customer. After launch, look at those numbers weekly and let them decide what you build next, not the longest feature request in your inbox.
A Practical MVP Plan
- Discovery (one to two weeks): the question, the users, the core action and what is out of scope.
- Design and build in slices: something usable on your own phone within weeks, not months.
- Private pilot: a small group of real users, watched closely.
- Public launch and weekly iteration.
If you have an idea and want a straight answer on what the first version should include, what it would take and what to leave for later, talk to us. We would rather help you launch something small and real than something large and late.