What should your first MVP include?

1. Choose the user, problem, and question.

An MVP (minimum viable product) is an early, usable version of a product built to test an important assumption. Before listing screens, write down who will try it, what they struggle with today, and what you need to learn from their use.

Use this sentence: “For [specific user], the first release helps them [complete a task], so we can learn [whether a specific assumption holds].” If the question is only whether people understand a screen, a prototype may be enough.

2. Describe the whole journey.

Write the steps from arriving at the product to receiving a useful result. Include what the person provides, what the product does, and how they know the task is finished. A collection of attractive screens is not enough if the user gets stuck between them.

For a hypothetical booking tool for independent tutors, the first journey could be: a tutor shares available times, a student chooses a slot, and both receive a confirmation. Write down how a cancellation or an already-taken slot is handled too.

3. Separate essential features from later ideas.

For each feature, ask: “Without this, can an early user complete the journey, and can we answer our question?” Keep features that are necessary for either. Put the rest in a later list with a reason to revisit them.

In the tutor example, availability, booking, confirmation, and preventing duplicate bookings belong in the first scope. Custom profile themes, a referral programme, and a multi-location dashboard could wait if they do not serve the initial test.

Some work can be manual at first. A founder might onboard the first tutors personally rather than building a self-service setup wizard. Make that manual work explicit, including who will do it and what users should expect.

4. Decide whether a prototype is enough.

A clickable prototype is useful for checking navigation, wording, and whether someone understands an interaction. It does not establish that a service works with real data, that people will return, or that they will pay.

If you need to observe real bookings, uploaded files, or another completed task, that part of the product needs to actually work. A small technical experiment may also be useful before committing to a feature that depends on an uncertain integration. Choose the next step based on the uncertainty you need to resolve.

5. Keep the basics in the first release.

A smaller scope still needs to behave responsibly with the information and promises it handles. Discuss these essentials before estimating the project:

• Access: who can see or change each piece of information, and whether accounts are needed.
• Error handling: what happens when an input is invalid, a request fails, or someone repeats an action.
• Data: what is stored, how it can be removed, and what needs backup or recovery.
• Dependencies: external services, running costs, and what happens when a provider is unavailable.
• Use and support: supported devices, accessible core interactions, and a clear way to report a problem.

6. Decide what you will learn after launch.

Choose an observation that relates to your original question. For the tutor example, ask whether students can complete a booking without help, where they abandon the flow, and whether tutors use it again.

Agree who will invite early users, collect feedback, and review it. If you collect usage events, decide which ones you need and how users’ privacy will be handled. Page visits alone will not tell you whether the booking journey is useful.

Write down what evidence would lead you to improve the flow, change the idea, or stop. An MVP is useful when it informs that decision, even if the next step is smaller than you expected.

7. Prepare a brief before hiring a developer.

You do not need a polished specification. A short, clear brief makes the scope conversation more useful. Include:

• The intended user, their current workaround, and the question you want to test.
• The main journey, with a concrete example of a successful outcome.
• Two lists: included in the first release, and intentionally deferred.
• Required data, integrations, designs, and any existing code.
• Your budget range, timing constraints, and who makes scope decisions.
• How you will check the release, who owns the accounts and code, and what support is expected afterwards.

Ask for an estimate tied to written scope and acceptance criteria. For the booking tool, one criterion might be: “When two students try the same slot, only one booking is confirmed and the other student gets a clear explanation.” That is easier to review than “the booking page is done.”