Desenvolupament mvp

What desenvolupament mvp actually means

Desenvolupament mvp is the Catalan phrase for MVP development: building a minimum viable product. The useful definition is narrower than the popular one. An MVP is the smallest product you can operate responsibly that still produces useful evidence from a real user following a real path. It is not a polished demo, and it does not prove adoption, revenue or product-market fit. It gives evidence about one path under one set of conditions.

This guide comes from IVRYN, an independent Paris studio that runs several separate products, each with its own audience and domain. That context shapes the advice toward tightly scoped, measurable releases and accountable automation. It draws only on the studio's published methodology and its guide to prototypes, MVPs and proofs of concept, and it reports no client results or comparative studies, because none are claimed.

Check whether you need an MVP at all

MVP development is not always the right first step, because a different artefact may answer the open question more directly. If the team cannot agree on how the user flow should work, a prototype is usually the better tool. If everything hinges on one uncertain technical assumption, such as an API, algorithm or hardware interaction, a proof of concept isolates that risk. An MVP makes sense once the problem, path and operating boundary are understood well enough that real use is the missing evidence.

A convincing prototype does not prove production quality, and a working technical proof does not prove demand. The artefact is chosen by the question it must answer, not by which label sounds more advanced.

• Unclear flow or wording: prototype first.
• One risky technical dependency: proof of concept first.
• Known problem and path, missing real-use evidence: MVP.

Write the decision before writing code

Write a one-sentence decision before choosing a format. For example: if invited users complete the export flow without help, we invest in scheduling; if not, we revisit the data model. You set the thresholds; what matters is that the result can genuinely change the plan.

Around that sentence, name who will use or inspect the product, where it will run, which data it may touch and what the result cannot demonstrate. That last item is easy to skip and worth keeping. It stops a stakeholder demo from becoming an accidental production commitment and stops a narrow success from being presented as proof of the whole idea.

This is where problem clarity becomes concrete. Start from a specific user, task and context, separate observed behaviour from assumptions, and list what the product will deliberately not do. Writing down assumptions and exclusions early keeps a polished interface from hiding an undefined problem.

Scope a small, testable MVP release

Minimum should describe scope, not care. Pick one end-to-end path that serves the decision sentence and cut everything else. Each release should be small enough that you can tell what changed and why the evidence moved.

Constraints belong in the scope document, not a later cleanup. List security, privacy, accessibility and platform limits early, and collect only the data the feature and its operation require. Third-party services are dependencies with their own availability, policy and cost, so record what happens when one fails.

• Checklist: one user, one job, one path.
• A written list of exclusions.
• Each data field and why it is needed.
• External dependencies and their failure behaviour.
• The result that would change your plan.

Build accessible, recoverable critical flows

Because real people use an MVP, the critical path needs failure states, plain language and a way to recover. An error with no explanation or recovery path can end a session before it tells you anything about the problem you set out to test. Accessibility belongs here too: if some users cannot complete the path, your measurement describes your interface, not their need.

If the MVP includes AI-assisted features, the interface should say when output is generated, where human review is expected and what happens when a model or provider is unavailable. In a small release, responsible automation mostly means being explicit about these edges rather than hiding them.

Verify the release and measure outcomes honestly

Keep verification proportional to risk: automated checks, manual tests of the main flow, responsive visual checks and monitoring of the deployed route, as the product requires. A passing local build is not a production release; check the public endpoint before saying it shipped.

Tie measurable product outcomes to the decision sentence: completion of the chosen path, where users drop off and whether the expected behaviour appears. Lab scores such as Lighthouse are time-specific laboratory measurements: they are not a ranking, a guarantee of real-user performance or proof of business impact.

Hypothetical example: a three-person team wants to help freelance translators track invoice deadlines. The flow is agreed and no risky technology is involved, so they skip the prototype and proof of concept. They ship one path, add an invoice and receive a reminder, to a small invited group, collect only the fields reminders need, and note that the release cannot show willingness to pay. Their rule: if reminders are acted on, build payment tracking; if ignored, interview users before adding anything.