How to Define an MVP for an Indie Project

Reducing features too far can leave only a screen with no clear reason to use it. Define an MVP around the actions a user takes to reach a useful outcome, not around the smallest possible collection of components.

For example, a service that helps organize consultations may need to turn a short description into clear discussion points and next actions. An empty input field alone does not prove its value.

Ask these questions for every feature. If the answer is no, it is usually a Phase 2 candidate.

• Can users experience the core value without it?
• Does it help a first-time user solve the problem they came with?
• Can a mock, manual workflow, or static example test the hypothesis first?

Authentication, storage, external APIs, and notifications can be valuable, but they also add build and operating cost. Start with mock data or a limited manual workflow where possible, then add them when users have a reason to return.

There are exceptions when an account or integration is part of the value itself. The deciding factor is the product's core experience, not a generic MVP rule.

Do not defer features to an unstructured backlog. Define what evidence would justify each addition, such as frequent repeat usage for history or repeated requests for alerts when information changes.