The MVP development process, step by step

What the MVP development process actually needs to answer

The mvp development process is often described as a sequence of build steps, but it is more usefully understood as a sequence of decisions about evidence. Before a single feature is coded, a founder or small team needs to be honest about what they don't yet know: whether the problem is real, whether the proposed solution addresses it, and whether anyone will change behaviour because of it. An MVP is the smallest thing that can generate a trustworthy answer to those questions, not the smallest thing that can be shipped.

This framing matters because teams frequently confuse an MVP with a prototype or a proof of concept, which serve different purposes. A prototype tests whether an interface or interaction makes sense; a proof of concept tests whether something is technically feasible; an MVP tests whether the product creates value for a real user in a real context. Conflating these stages leads to either overbuilding a 'prototype' that nobody validates, or underbuilding an 'MVP' that never gets exposed to genuine use.

IVRYN, an independent product studio based in Paris, works across a portfolio of separately scoped products, including Imryn, Datvero, Cascads, Reef, Flare, Sealed, Crucible CLUB and Victor Laybats. Each has its own domain, audience and product page, and the studio's approach favours clear scope, measurable usefulness and responsible automation rather than one-size-fits-all playbooks. That plurality of small, bounded products is itself a useful lens on the MVP process: each product had to justify its own existence with a narrow, testable claim before expanding.

Step 1: Define the problem before the product

The first step in any credible mvp development process is writing down the problem in terms of who has it, how often, and what they currently do instead of using your product. If this description is vague or if the 'current alternative' is 'nothing, they just live with it,' that is a signal the problem may not be urgent enough to sustain adoption.

A useful discipline here is to separate the problem statement from any solution ideas. Teams that jump straight to 'we'll build a dashboard that does X' skip the step where they would have noticed that the underlying problem could be solved with a spreadsheet template or a manual service, which is often the fastest way to learn whether the problem is worth solving in software at all.

• Write the problem as a sentence about a specific user and situation, not a feature
• List the current workaround the user already relies on
• Note who would notice if the problem disappeared, and how

Step 2: Choose the right kind of small release

Once the problem is stated, the process forks depending on what kind of uncertainty is highest. If the biggest unknown is whether people understand and want to interact with the concept, a prototype focused on interface clarity is more appropriate than a working MVP. If the biggest unknown is whether a technical approach is even possible, a proof of concept answers that more cheaply than a polished release. If the biggest unknown is whether real usage produces real value, that is when an MVP is justified.

This distinction, covered in more detail in IVRYN's guide comparing prototypes, MVPs and proofs of concept, is not academic. Building a full MVP to answer a question that a five-screen prototype could answer wastes weeks; building a technical proof of concept and mistaking it for market validation wastes trust with early users who encounter something unfinished and assume the product itself is unfinished.

A small testable release, in any of these three forms, should be scoped so that its outcome can change the next decision. If the result of the test would not change what the team builds next, the test was not worth running in that form.

Step 3: Build the smallest accessible version, not the smallest possible version

A common failure mode in mvp development is treating 'minimum' as licence to skip basic usability and accessibility. An MVP that only a technically sophisticated tester can operate will not produce honest signal about real users, because the friction of using it becomes indistinguishable from the friction of the underlying problem. Accessible interfaces are therefore not a later-stage polish item; they are part of what makes early data trustworthy.

This does not mean an MVP needs comprehensive design work. It means the core interaction - the one action that delivers the value being tested - should be usable without special knowledge, should work with a keyboard and screen reader where relevant, and should not silently fail. Everything else, including account systems, settings, and edge-case handling, can reasonably wait.

Scoping the build this way also keeps cost proportional to the question being asked. A team spending disproportionate engineering time on infrastructure for scale it does not yet have is usually avoiding the harder, more uncomfortable step of putting an imperfect but usable version in front of real people.

Step 4: Decide what 'measurable outcome' means before you launch

An MVP that launches without a predefined measure of success will almost always be judged after the fact by whichever number looks best, which defeats the purpose of testing. Before release, the team should agree on one or two measurable product outcomes tied directly to the problem statement from step one - for example, whether users complete the core action, return to it, or would be worse off without it.

Vanity metrics such as signups or page views rarely answer the underlying question. A more useful practice is to define, in advance, what result would make the team stop, what result would make them continue as-is, and what result would make them adjust the approach. Writing these three thresholds down before launch prevents post-hoc rationalisation once real numbers arrive.

Because no first-party study or dataset is being claimed here, teams should be cautious about treating any single early metric as proof of long-term viability. Early signal from a small release indicates direction, not certainty, and should be treated accordingly when deciding what to build next.

Step 5: Loop, don't linear-launch

The mvp development process is a loop, not a line from idea to launch to done. Each release should feed a revised problem statement, a revised scope for the next small test, and a revised understanding of who the product actually serves. Teams that treat the MVP as a one-time gate before 'the real product' tend to lose the discipline of small testable releases exactly when it matters most, during early growth.

Cost discipline matters throughout this loop. Every additional feature or integration added between releases should be weighed against whether it answers an open question about the problem or simply adds surface area. Responsible automation - building only what genuinely reduces manual effort without adding fragile dependencies - is one practical way to keep each loop small and reversible.

A worked example (illustrative, not a case study)

To make this concrete, consider a hypothetical two-person team building a tool to help freelance translators track project deadlines across multiple clients. This is an illustrative example only, not a documented case or claimed outcome.

Step 1, they write the problem as: 'freelance translators managing 4+ concurrent clients miss deadlines because reminders live across email, spreadsheets and sticky notes.' Step 2, since the biggest unknown is whether translators will trust a third-party tool with deadline data at all, they choose a simple prototype: three mocked screens showing how deadlines would be entered and surfaced, shown to ten translators. Step 3, once the concept resonates, they build the smallest accessible MVP: a single screen to add a deadline and see a sorted list, keyboard-operable, no accounts yet, using each translator's email as the identifier. Step 4, they define success in advance as: at least half of testers add a deadline within their first session, and at least a third return within a week without prompting. Step 5, based on that result, they decide whether to add multi-client tagging or to revisit the problem statement entirely.

This kind of worked example is useful precisely because it separates the decision from the outcome; the numbers here are illustrative thresholds a team might set, not a report of results.