Launch your MVP and learn fast

An MVP is the smallest real product that answers your biggest question. MVP stands for minimum viable product: minimum, because it leaves out everything that isn’t needed yet; viable, because real people can use it, rely on it and pay for it.

It is not a clickable mock-up, which shows what a product might look like but can’t actually be used. Nor is it a cheap, rushed copy of the full product. A good MVP does a few things properly and leaves the rest out on purpose.

Its job is to replace opinions with evidence. Before an MVP, everyone has a view on what customers want. After it, you know what they did: whether they signed up, came back, told a friend or paid. That knowledge is what the next stage of the product, and often the next round of funding, is built on.

Every idea rests on a few assumptions, and one of them is the riskiest. Perhaps it is whether shops will book deliveries in an app instead of calling a rider they know. Perhaps it is whether parents will pay for small classes when large ones cost less. Perhaps it is whether salon owners will set up software on their own, without a salesperson beside them.

We start by writing those assumptions down with you and picking the one that would sink the idea if it were wrong. The MVP is designed to test that one first. Everything that doesn’t help answer it waits.

This is also when we decide what success looks like, before anything is built: a number of sign-ups, a share of users who come back in their second week, a number of paying customers. Agreeing it up front stops anyone reading the results to suit themselves later, including us.

The hardest part of an MVP is leaving things out. Founders arrive with a long list, and every item on it feels essential. We go through it with you and sort each feature into three piles: now, later and never.

A feature goes into “now” only if the MVP can’t answer its question without it. Sign-up, the core action and a way to pay usually make the cut. Referral schemes, detailed profiles, dashboards for every role and settings for rare cases usually wait. A few land in “never” once someone says out loud why they wanted them.

What stays in is built properly. A small product that works every time teaches you more than a big one that breaks, because users judge the idea by how it feels to use.

The “later” pile isn’t wasted. It becomes the list for the next releases, reordered by what the MVP’s users actually ask for.

Many steps can start as a person behind a simple screen. Matching orders to drivers, approving new sellers, writing a report or checking a document can all be done by your team at first, while the product still feels smooth to the user.

This keeps the MVP small, and it teaches you how the step really works before you pay to automate it. The delivery startup we back in Jaipur began with its own riders and a shared spreadsheet. The dispatch engine that now groups nearby orders into single trips came later, built by our engineers once FIRELIFE backed it and the way the work ran was well understood.

When a manual step becomes the bottleneck, that is the signal to automate it. By then you know exactly what the software has to do.

We need your time, access to your customers, and honesty about what you don’t know yet.

Time, because an MVP moves quickly and decisions can’t wait a week. A founder who answers questions the same day makes more difference than any tool we could choose.

Customers, or at least a way to reach them. We help you speak to a handful of them before we build, and the pilot needs real users rather than friends being polite. If people are already waiting, such as a WhatsApp group of early sign-ups or a few businesses that said yes, bring them.

And honesty about the unknowns. The assumptions you are least sure of are exactly the ones the MVP should test. Telling us where you are guessing is how we make sure the money is spent there.

Most MVPs should start where they are quickest to build and easiest to change, and that is often a web app. It works on every phone and computer, needs no app store review, and can be updated many times a day.

A mobile app makes sense first when the idea depends on the phone: location, the camera, notifications or working without a signal. A rider app, a field app or a check-in app belongs on the phone from the start. Flutter and React Native let one app run on Android and iPhone, which keeps the cost close to a single build.

Sometimes part of the journey needs no app at all. Bookings by WhatsApp message, a simple form or an existing tool can carry a step while the core is tested. The health startup we back in Ahmedabad lets patients book a consultation by sending a WhatsApp message, alongside its own app in three languages.

Some ideas can’t cut corners, however small the first version is. A health app must verify its doctors and record each patient’s consent; online consultations in India follow the Telemedicine Practice Guidelines, which the health startup we back built its platform around. A lending product follows the RBI’s rules on digital lending, from the Key Fact Statement a borrower sees before signing to the way repayments are collected. A product for children needs a parent’s consent under India’s data protection law, and a product for customers in Europe or the UK follows the GDPR.

These rules shape the MVP from its first screen, so we find them at the start rather than after launch. The rest of the product can stay small; the rules can’t. That is why an MVP in health, money or education takes more care than one for a simple booking service, and the plan says so plainly.

An MVP should be small, not flimsy. We build it on standard, well-supported tools such as Next.js, Node.js, Flutter and PostgreSQL, with clean code, tests around anything that handles money or personal data, and hosting that can grow with it.

That way, when the MVP works, it becomes the first version of the real product rather than something to throw away. New features are added to it, manual steps are automated, and more users are carried on the same foundations.

We also keep a short record of the decisions we made and why. A future engineer, an investor’s technical adviser or your own first hire can then understand the product in an afternoon instead of a month.

We set up measurement before the first user arrives. The MVP records the steps that matter for your question: who signed up, who completed the core action, who came back, who paid, and where people gave up.

During the pilot we also talk to users. Numbers show what people did; conversations explain why. Together they tell you whether the riskiest assumption held, and what to change if it didn’t.

If you can, charge from the start. A payment, even a small one, is the clearest sign that the product solves a real problem. UPI, cards and subscriptions can be live in the first version through Razorpay or Stripe, so you learn what people will actually pay for.

An MVP ends with a decision. If the assumption held, you build on it: the next features from the “later” pile, automation for the steps done by hand, and the polish the first version skipped. If it partly held, you change direction and test again, usually reusing most of what was built. If it failed, you stop before spending more, which is a good result too.

We make that decision with you, from the numbers and the conversations together. If you carry on, we can stay as your engineering team: planning and shipping with you, and reviewing product, results and spending every month, the way we work with the startups FIRELIFE backs.