How to develop an mvp

How to develop an MVP, starting from one precise problem

If you are working out how to develop an MVP, start with the problem rather than the feature list. A minimum viable product is a real, bounded release that produces interpretable evidence for one named decision. That decision might be whether to keep investing in a workflow, narrow the audience, or stop. If you cannot state the problem in one sentence, naming who has it and what it costs them today, any build will be guesswork.

IVRYN is a Paris studio that runs several products, each scoped to its own audience. That context shapes the advice here. It leans towards narrow scope, usefulness you can measure and automation you can account for. This article applies those preferences to MVP work. It is not a report on a study, and it does not describe outcomes from any particular product.

Decide which question your MVP answers

Separate three kinds of work before scoping anything. A proof of concept tests one narrow technical assumption, such as whether an integration behaves as expected, whether a computation fits within a constraint, or how a specific failure case is handled. It does not establish demand, usability or operational readiness. A prototype tests whether people understand an interaction. An MVP is actually released, so a bounded group of real users can use it and you can collect evidence. IVRYN's guide to prototypes, MVPs and proofs of concept sets out these differences, and mixing them up is how teams end up answering the wrong question.

Be modest about what that evidence means. The guide notes that a deployed MVP does not, by itself, prove regular use, adoption, revenue or product-market fit. So write down the decision the release informs, the hypothesis behind it, and the result that would push you each way. For example: "If invited agencies send two consecutive weekly reports through the tool, we will automate the third data source; if not, we will interview them before building more." A statement like that tells you what to build, who to invite and what to measure.

Scope the smallest release that is still safe to ship

Map the one path a user follows from arriving with the problem to leaving with it handled. Every screen, integration and setting that is not on that path is a candidate for removal. Manual steps behind the scenes are acceptable early on, as long as you are honest about what they cost and where they fall short.

Cutting scope has a floor, though. Because an MVP is released rather than merely demonstrated, its boundary can include authentication, authorisation, privacy, accessibility, error handling, monitoring and recovery wherever the context requires them. "Minimum" applies to features, not to consequential safeguards. If real people sign in, share data or depend on the output, the protections around that are part of the minimum.

Plan releases small enough to judge. A release that bundles five changes makes it impossible to tell which one mattered. One meaningful change per release, each with an expected effect, keeps the evidence readable.

• Write the problem, the decision and the hypothesis on one page.
• List the steps of the core user path and cut everything else.
• Mark which steps are automated and which are handled manually.
• List the safeguards your context requires and keep them in scope.
• Define what "done" means for each release before you build it.

Build accessible interfaces from the first release

Accessibility is not polish to add later. If keyboard users, screen reader users or people with low vision cannot complete the core path, your MVP will undercount real need and give you a distorted signal. Fixing structure later is also more expensive than getting it right while the interface is still small.

Focus on the basics along the core path: semantic headings and labels, visible focus states, sufficient contrast, form errors explained in text, and flows that do not depend on colour or precise pointer movement. Check these by hand on every release, because automated checkers help but do not catch everything.

Reliability checks: measure outcomes and verify the release

Measure whether the problem was handled, not just whether people clicked. Useful MVP metrics tie back to the decision: tasks completed, time compared with the old method, or repeat use when the need recurs. Sign-up counts rarely say whether the product is useful.

Reliability depends on release discipline as much as on metrics. IVRYN's public methodology page describes how it treats product evidence, and the same spirit applies here: decide in advance what you will count, record what changed, and claim no more than the data supports. A local build is not a successful release. Until the public endpoint has been checked, you only know the product works on your own machine, so report a deployment as done only after that check.

• Were success and failure criteria fixed before launch?
• Is each metric tied to the core path rather than general activity?
• Does the core flow show clear failure states and offer a recovery path?
• Is data collection limited to what the feature actually requires?
• Are third-party dependencies noted, with their availability and cost constraints?
• Was the public endpoint checked after deployment, not just the local build?
• Is there a log of what changed in each release and which version is live?
• Are manual steps disclosed to users where it matters?
• Was the core path checked for accessibility on this release?

Worked example (hypothetical): a reporting tool for small agencies

Example only, not a real project. A two-person team believes small marketing agencies spend hours each week assembling client reports by hand. The decision they need to make is whether to automate a third data source or rethink the audience. The MVP supports one report template and two integrations, with the third source handled manually. Because agencies will connect client accounts, sign-in, access limited to each agency's own reports, and a clear error with a retry option when an integration fails all stay in scope.

Release one goes to a handful of invited agencies after keyboard and screen reader checks and a check of the live address. The agreed signal is whether most send two consecutive weekly reports through the tool. That informs the automation decision; it does not prove adoption. Release two changes only one thing, automating the manual source, so its effect can be read on its own. If agencies stop after one report, the team talks to them before adding features, because the problem or the audience may be wrong rather than the build.