Bygging av MVP-en: loopen fungerer fra start til slutt

Byggeteknikken kommer fra vibe coding-kurset (Lovable/Replit, iterations, rollbacks). Her går vi gjennom hva som skiller et produkt fra et hobbyprosjekt: rekkefølgen du bygger i, og to lag som nybegynnere alltid glemmer.

Skjelett før skjønnhet

Mål én: hele loopen kjører fra start til slutt, uansett hvor klønete – registrering → gjør tingen → få resultatet. Først da polerer du individuelle trinn. Hvorfor den rekkefølgen: de skumleste problemene er sømmene («trinn 3 er umulig uten data fra trinn 5»), og de dukker bare opp når loopen kjører helt gjennom. Bedre å fange dem på dag én enn å oppdage, etter en uke med polering av landingssiden, at produktet ikke kan fullføres i det hele tatt.

Denne regelen er eldre enn webutvikling. Da Pixar laget den første Toy Story, klippet de en grovversjon av hele filmen ut fra skisser – de såkalte «reels» – og først da de var sikre på at historien holdt fra begynnelse til slutt, brukte de måneder på å gjengi bilder. Hele greia grov først, detaljer vakre deretter. Programvare fungerer på samme måte.

En sokratisk pause

Du har åpnet produktet for første gang. Hva er på den første skjermen? Ikke en fullstendig oppgaveliste, ikke en utfylt feed – tomhet. Og det er der det avgjøres om du blir eller lukker fanen. Tenk: hva må være på den tomme skjermen for at du skal vite hva du skal gjøre?

Lag 1: empty states

En ny bruker har ingen data: tom liste, tom historikk. Et hobbyprosjekt viser bare tomhet; et produkt veileder: «Ingenting her ennå. Last opp din første – her er knappen.» Hva du skal be AI-en om: «For hver liste og skjerm, bygg en empty state: hva dette er, hva det er til for, og en knapp for den første handlingen». Første inntrykk lever akkurat her – på skjermen hobbyprosjekter lar stå tom.

Lag 2: brukervennlige feilmeldinger

Feil fil, wifi-en blinket, betalingen mislyktes. Et hobbyprosjekt sier ingenting, eller skremmer folk med «Error 0x80070057». Et produkt forklarer og tilbyr en vei ut: «Denne filen er over 100 MB – komprimer den eller del den opp.» Formelen for en god melding: hva som skjedde + hva du skal gjøre. Oppgaven: «Hver feilmelding i klart språk: hva som skjedde og hva du skal gjøre. Og vis meg en liste over alle feilmeldingene» – den siste delen lar deg redigere all tekst samtidig, med én stemme.

Nybegynnermyter

• «Feil er unntakstilfeller, jeg skriver dem senere.» Én av tre personer støter på en feil ved sitt aller første besøk: feil format, musen glapp, ustabilt nettverk. Det er ikke unntaket, det er midten av opplevelsen.
• «Det er klart for meg, så det er klart for alle.» Du kjenner produktet fra innsiden – du er en blindtester. Det må være klart for noen som ser skjermen for første gang.
• «Jeg gjør det pent, så sjekker jeg logikken.» Motsatt rekkefølge: fungerende loop først, skjønnhet deretter. Et nydelig ødelagt produkt er et dyrt bilde.

«Andre folks hender»-testen

Du kjenner dette trikset fra tidligere kurs – nå er det et obligatorisk aksepttrinn. Noen fra målgruppen din går gjennom loopen foran deg, i stillhet, og du hinter ikke og forklarer ikke – du bare ser hvor de snubler. I «Don't Make Me Think» viste Steve Krug at 3–5 ekte mennesker er nok til å finne de fleste problemene; du trenger ikke et dyrt laboratorium. Tre snubler = tre oppgaver til i morgen. Fortsett å polere loopen til en ny person kommer gjennom den uten et eneste spørsmål – det er hva MVP-klar betyr.

Hvor dette går galt: polering av feil ting

Den klassiske MVP-byggefeilen ser slik ut: gründeren bruker en uke på å perfeksjonere en knappanimasjon og en landingssidegradient, og testbrukeren snubler ved inngangsdøren – de vet ikke hvor de skal klikke etter registrering. Skinn polert, skjelett ødelagt. Rekkefølgeregelen eksisterer nettopp for dette: før en ny person kan gå gjennom loopen fra start til slutt, er polering av en enkelt skjerm for tidlig. Først «fungerer fra start til slutt», deretter «vakkert på hvert trinn». Motsatt rekkefølge er den dyreste måten å tilbringe en uke på.

Hvordan dette kobles til andre kurs

Iterering, tilbakerulling til en fungerende versjon og arbeid med en AI-assistent er teknikk fra vibe coding-kurset. Og empty states og brukervennlige feilmeldinger du bygger her, driver direkte konvertering til første verdi – en metrikk fra dette kursets analyseleksjon. Alt henger sammen: det du bygger nå er det du vil måle senere.

Gjør dette nå (5 minutter)

Åpne produktskissene dine og finn en ny brukers første skjerm. Veileder empty state-en dem til en første handling, eller er den bare tom? Hvis den bare er tom, skriv AI-forespørselen for empty states akkurat nå, før du glemmer det.