A startup MVP checklist for Indian founders

An MVP is the smallest complete product that lets you test an important business assumption. It still needs to work for the person using it. A collection of unfinished features will tell you little about whether customers value the idea.

For founders planning a product in India, the brief should describe one audience, one important journey and one decision the first release will help you make. “An app for local services” is a starting point. “Allow an apartment resident to request a service and let an operator confirm the slot” is a buildable journey.

Write the assumption before the feature list

State who has the problem, how they deal with it now and why they might try your product. Identify the riskiest assumption: willingness to enquire, repeat usage, operational feasibility or willingness to pay.

Choose a measurement that reflects that assumption. A completed booking can be more informative than a page view. Review the result alongside customer interviews; a number without context can lead to the wrong next feature.

Map the whole journey

Write down what happens before and after the main action. A booking needs availability and a confirmation. An order needs fulfilment and a response when stock is unavailable. A subscription needs a clear account state when payment fails.

Do not forget the person operating the business. A simple admin screen to review requests may be more important at launch than a polished secondary customer feature. Keep manual work deliberate and visible so the team knows what it must handle.

Decide whether you need a website or an app first

A web product can be shared by a link and updated without an app-store release. A mobile app can be useful when repeat use, notifications, device features or offline work are central to the journey.

The website versus mobile app guide offers a more detailed decision checklist. Choosing one platform for the first release can reduce scope, provided it still serves the intended audience.

Plan integrations and sensitive information

List the services you depend on: payments, messaging, maps, identity or an existing business system. Confirm access, provider onboarding and sandbox availability early. Put failure cases into the acceptance criteria, including duplicate requests, interrupted connections and declined payments.

Decide what customer information is necessary, who can access it and when it should be removed. Request appropriate professional advice for regulated activity or legal requirements; the software specification should reflect those decisions rather than inventing them.

Agree a release checklist

• The core journey can be completed on the intended devices.
• Important failure states explain what the user can do next.
• Staff can view and resolve operational exceptions.
• Hosting, domain and provider accounts have named owners.
• Backups, error reporting and support responsibilities are documented.
• Enquiry or conversion measurement is tested with appropriate consent.
• Source-code access, handover and the support period are agreed in writing.

Reserve room for learning

Avoid spending the entire budget on the launch feature list. The first users may reveal unclear language, a missing operational step or a problem with the original assumption. Decide who will review that evidence and how improvements will be prioritised.

Our startup MVP development service covers discovery, a focused release and handover. Discuss your MVP with Mukul Chauhan with your audience, core journey and the question you want the first version to answer.