How to plan an MVP in 2026

Write the question before the feature list

Decide what the first product must help you learn. That question becomes a filter for scope and prevents attractive but non-essential features from taking over.

• •Will the target user complete the core journey
• •Will they return or continue the workflow
• •Can the business deliver the promised value
• •Which assumption would stop the idea if false

Choose one complete journey

A narrow product can still feel complete. Concentrate on the path from first intent to a meaningful result, including the states and messages that make that path understandable.

Keep temporary operations visible

Some early processes can remain manual. Document them rather than pretending they do not exist. This keeps the product scope focused and shows where later automation may create the most value.

Plan the next decision, not the final platform

Define what evidence will influence the next release, who will review it and which parts of the product are deliberately deferred. A good MVP creates direction as well as software.

Write a brief that someone can estimate

Describe a typical task in sequence: who starts it, what information they provide, what the product does and what result they receive. Identify the tools involved and any important constraints. This gives a designer or engineer more useful context than a list of screens alone.

You can begin with a rough sketch or an existing process. Mark what you know and what you are assuming. If the audience, core journey or business model is still unsettled, resolve those questions rather than disguising them as features.

• •Primary user and the problem they face
• •Beginning and end of the core journey
• •Required data, permissions and external tools
• •Budget constraints and the decision the release should support

Separate launch essentials from later improvements

For each feature, ask whether the primary user can reach the intended result without it. If yes, it may belong in a later phase. If no, explain why it is essential and include the states needed for it to work. Login, validation and recovery from errors may not be exciting features, but they can be necessary for a coherent journey.

A planning example: a product could start with a request and review workflow while the team handles an internal follow-up manually. Later automation should depend on what the team learns. This is a scope illustration, not a Studio89 client result or a recommendation to skip essential safeguards.

Plan testing before calling the product ready

Walk through the main journey and the ways it can fail. Test incomplete information, access restrictions, empty states and unavailable external services where they apply. Include the screens people use on mobile, not only the desktop view shown in a presentation.

Agree who supplies test information and who reviews the first version. A visible review cycle helps resolve misunderstandings while the work is still in progress. A delivery date should follow the agreed scope and dependencies; there is no single timeline that fits every MVP.

• •Can the user complete the primary task?
• •Do errors explain what needs to happen next?
• •Are permissions and data visibility appropriate?
• •Can the owner operate the process after handover?

Set a first-stage budget, not a lifetime product budget

Studio89 Product Blueprints start from £1,500, and focused MVP work starts from £5,000. These are starting points rather than a quote for every idea. The Blueprint defines the problem and scope; the build is a separate engagement based on the agreed journey and complexity.

Allow for hosting, external services and any later improvement work separately. Compare estimates using the same brief, including integrations, testing, handover and exclusions. At Studio89, scope and price are agreed in writing before work begins, and changes to that scope are quoted separately.

Decide how you will review the first release

Choose the evidence that informs the next decision before adding more features. That could be whether people complete the journey, where they need help or which manual step prevents the team from serving them. Avoid collecting numbers without a decision they will influence.

Record who will review the evidence and what would justify the next phase. You may need to improve the first journey, test a different assumption or stop work that is not proving useful. An MVP plan should leave room for all of those outcomes rather than treating more development as the only possible next step.

Choose the next conversation

If you need help choosing the journey, a Product Blueprint can create a clearer direction before engineering. If the journey is already defined, discuss a focused build. Bring the idea, any existing workflow and the constraints you know; you do not need a polished pitch deck.

You own the agreed product, code and accounts at handover. Further improvement is optional: take the work in-house or discuss another scoped phase. The pricing page sets out starting points and deliverables so you can decide whether the conversation fits your stage.