Från idé till MVP — byggd smalt nog att bli klar.

Den minsta version som kan ge ett riktigt svar på den fråga som avgör om produkten ska byggas vidare — oftast om någon vill använda den och betala för den. Det är inte en billig eller halvfärdig produkt: den del som finns med ska hålla full kvalitet, annars mäter ni hur dåligt något är byggt i stället för om det behövs. Skillnaden ligger i hur mycket som är med, inte i hur väl det är gjort.

Vanligtvis några månader från start till lansering. Det som styr är hur hårt version ett är avgränsad, inte hur snabbt någon kodar — och det är därför vi lägger tid på avgränsningen först. En omfattning som halveras i ett möte sparar mer tid än något beslut som fattas senare i projektet.

Kostnaden följer omfattningen: antalet användartyper, om betalningar ingår, hur många externa system som ska kopplas in och om det behövs både app och webb. Vi går igenom det på ett kostnadsfritt möte och återkommer med ett intervall och vad som ligger bakom. Ofta blir siffran lägre än väntat, eftersom omfattningen krymper under samma möte.

Då har den kostat en MVP i stället för ett år, och ni vet det utifrån riktiga användare i stället för utifrån en gissning. Det är hela poängen med att bygga litet först. Vi bygger in mätning från dag ett just för att det svaret ska gå att läsa av tidigt nog att göra något åt.

Ja. Kod, konton, data och miljöer är era och överlämnas i ett skick där ett annat team kan ta vid. Det är särskilt viktigt för en tidig produkt, eftersom en investerares granskning brukar ställa exakt den frågan.

Ja, och många gör det tills det finns skäl att anställa ett eget team. Vi kan också bygga med det som mål från början: dokumentation, struktur och överlämning planerade för att en intern utvecklare ska kunna ta över utan att produkten stannar.