Original: https://experimentet.se/guider/prototyp-mvp-fardig-produkt/
Språk: svenska

Guide / Avgränsning

# Vad skiljer en prototyp från en MVP?

Orden används olika i olika projekt. Bestäm därför vad versionen ska användas till, vilka som ska prova och vad leveransen faktiskt omfattar.

Av Experimentet · Publicerad 8 september 2026

## Det korta svaret

En prototyp prövar en idé eller ett flöde i ett avgränsat test. En MVP är en liten första produktversion som hjälper er att lära av verklig användning. En produkt i drift behöver dessutom tydligt ansvar för bland annat tillgänglighet, data, fel och support. En MVP kan vara i drift; begreppen beskriver olika aspekter av produkten.

## Jämför vad ni behöver få ut.

Så skiljer vi på versionerna hos Experimentet

| Version | Huvudfråga | Typisk användning |
| --- | --- | --- |
| Prototyp | Förstår användaren idén och flödet? | Avgränsat test med utvalda användare och överenskommen data. |
| MVP | Ger en liten första version tillräckligt värde för att användas? | Verklig användning i en avgränsad målgrupp, med krav som passar användningen. |
| Produkt i drift | Fungerar tjänsten löpande och vem ansvarar när något går fel? | Kunder eller medarbetare använder tjänsten i sitt arbete eller sin vardag. |

En produkt blir inte ”färdig” i betydelsen att den aldrig behöver ändras. Inför lansering handlar det om att de överenskomna kraven är uppfyllda och att någon kan ta ansvar för driften.

## Vad kan en prototyp visa?

En prototyp kan göra en idé konkret, pröva en teknisk del eller visa om användaren klarar en uppgift. Anta att ni vill bygga en kundportal. En prototyp kan låta kunden hitta en order och förstå dess status med exempeldata.

Testet kan visa att ett begrepp är oklart eller att nästa steg saknas. Det visar däremot inte att en integration är stabil i drift eller att kunderna kommer att logga in varje vecka. Sådana frågor behöver andra observationer och ett annat testupplägg.

[Vårt illustrativa kundportalexempel visar ett möjligt flöde.](https://experimentet.se/produktexempel/kundportal/)

## Vad får inte försvinna när en MVP avgränsas?

Ta bort funktioner som inte behövs för att pröva värdet. Behåll det som den faktiska användningen kräver. Om versionen hanterar riktiga kunduppgifter måste åtkomst fungera för den användningen. Om den tar betalt behöver köp, misslyckade betalningar och ansvar vara genomtänkta.

En smal produkt kan exempelvis ha en användarroll och ett enda beställningsflöde. Det är en annan avgränsning än att lämna felhanteringen odefinierad.

## Fyra frågor innan ni beställer.

1.  **Vilket beslut ska versionen stödja?** Fortsätta bygga, ändra ett flöde, testa efterfrågan eller börja sälja?
2.  **Vilka ska använda den?** Testpersoner under handledning, en pilotgrupp eller alla kunder?
3.  **Vilken data används?** Exempeldata, avgränsade kopplingar eller verkliga kunduppgifter?
4.  **Vad räknas som levererat?** Beskriv flöden, tester, överlämning och vad som uttryckligen återstår.

## Så börjar ett uppdrag hos Experimentet.

Vi börjar med en fungerande prototyp, test med tänkta användare och ett beslutsunderlag. Om ni vill gå vidare avtalas utveckling för lansering separat. [Läs exakt vad det första uppdraget omfattar](https://experimentet.se/leverans/) eller [hur vi arbetar med MVP-utveckling](https://experimentet.se/mvp-utveckling/).

## Osäker på vilket steg ni behöver?

Beskriv vad ni vill få svar på och vem som ska använda produkten.

[Beskriv ert projekt ↗](https://experimentet.se/kontakt/)