What should an app MVP actually include?

Define the promise before the feature list

An MVP starts with a promise to a specific user. It might help a customer book a service, help a team approve a request, or help a member track a recurring activity. The promise should describe an outcome, not an interface. “Customers can arrange a suitable appointment without a phone call” is stronger than “The app has a calendar and notifications.”

Write the core loop as a short sequence: a user arrives with a need, takes an action, receives a result and knows what to do next. This loop is the centre of the MVP. Every proposed feature should answer one of three questions: does it enable the action, make the result reliable or help the team learn whether the promise is working?

A clear promise also limits the audience. An MVP for one type of customer can be more useful than a broad app that tries to serve everyone. Define the first user, situation and success outcome. Other audiences may matter later, but adding them at launch often creates complex permissions, content and workflows before the first loop is proven.

Include the complete core journey

The MVP needs more than a visually attractive first screen. Include the steps required to start, complete and confirm the main task. If a user books, they need availability, relevant details, confirmation and a way to change or cancel. If a staff member records information, they need the right fields, validation, save behaviour and a clear result.

Look for hidden work around the core task. Does a user need an account, consent, payment, an invitation or a document? Is there a business process after submission? Who responds when something fails? These are not automatically extra features. If leaving them out makes the central promise unreliable, they belong in the first version.

Keep the journey narrow. A focused set of choices can be better than a large catalogue. Use realistic content and meaningful states, including empty, loading, error and success states. Users should understand what happened and what they can do next. A short journey that works is stronger evidence than many screens that only look complete.

Prioritise trust and usability

Users will judge the MVP by whether it feels safe and predictable. Provide clear explanations, accurate status, visible contact routes and honest limitations. Use plain language for permissions, payments, data collection and errors. If the app handles personal information, build appropriate access controls and retention decisions into the first release.

Accessibility is part of the core journey, not a later polish step. Check keyboard and screen-reader access where relevant, colour contrast, text size, focus order, touch targets and error messages. A product that excludes part of its intended audience is not proving its value properly. Good accessibility often improves clarity for everyone.

Do not confuse a small scope with low quality. The MVP can have few features while still being dependable. Remove optional settings, advanced reporting and broad personalisation if necessary, but do not knowingly leave the main journey unreliable. A manual review behind the scenes may be acceptable if users receive a correct result and the limitation is understood by the team.

Add only essential content and integrations

Content should answer the questions needed to complete the first task. Explain what the app does, what information is required, what happens next and where to get help. Do not fill the product with articles, badges or announcements before the core journey is clear. A small set of accurate messages is more useful than a large empty content area.

Integrations deserve a specific decision. Include a connection when the MVP cannot deliver its promise without it, such as a booking calendar, payment provider or existing account system. Delay a connection when it only adds convenience that can be handled manually during the test. Document temporary manual work so it can be measured rather than silently becoming a permanent risk.

Think about data quality and failure. What happens when an external service is unavailable, a payment is delayed or information changes? A clear fallback or support route can be more important than a new feature. The MVP should reveal whether the whole service works, not merely whether one screen can call an API.

Measure learning, not volume

Choose events that describe the core loop: activation, task start, completion, failure, support request, repeat use and the final outcome. Name them consistently and decide what counts before launch. Analytics should help answer a question, such as whether users understand the first step or where they abandon the process.

Avoid vanity measures as the main success criteria. Downloads, page views and total sessions may be useful context, but they do not prove that the app creates value. Combine quantitative signals with conversations, observation and support notes. A smaller number of successful users can teach more than a large number of curious visitors.

Set a review date and decision rules. Decide what would justify improving the MVP, narrowing the audience, changing the promise or stopping. This turns a launch into a learning cycle. Record what is known, assumed and still uncertain so new feature requests do not quietly replace the original goal.

Plan the next step without expanding too early

An MVP should make the next decision easier. After release, review where users succeed, where they need help and what they repeatedly request. A request is not automatically a priority; connect it to the core promise, frequency, impact and evidence. A feature that serves one loud request may be less valuable than a small improvement for most users.

Separate essential fixes from expansion. Reliability, accessibility, security, content accuracy and data quality may need attention before new functionality. Once the core loop works, add the next feature that removes a proven limitation or opens a valuable adjacent use case. Keep the product understandable as it grows.

The best MVP is not the smallest collection of screens. It is the smallest complete experience that can deliver value and produce trustworthy evidence.

Sources

• Events · Google Analytics
• Accessibility · MDN

Frequently asked

How many features should an app MVP have?

There is no fixed number. Include the capabilities required to complete one important user journey reliably. Remove features that do not support that journey or a specific learning question.

Should an MVP look polished?

It does not need every visual detail, but the main journey should be clear, accessible and dependable. Poor quality in the core task can invalidate the learning you hope to get.

Do analytics belong in the MVP?

Yes. Basic, purposeful measurement is needed to understand activation, completion, failure and return behaviour. Track only what supports a decision.

What should be postponed after an MVP?

Optional personalisation, advanced reporting, broad integrations and secondary audiences can often wait. Do not postpone reliability, security, accessibility or support for the core journey.