Prototyping på 48 timer: Fra idé til demo med AI

87% af de teams vi faciliterer har en fungerende prototype inden for 48 timer. Det er ikke tilfældigt. Det skyldes en skarp metode, de rigtige AI-værktøjer og én afgørende indsigt om hvad en prototype egentlig er.

Hvad er en hackathon-prototype?

En hackathon-prototype er ikke færdigt software. Den behøver ikke håndtere alle tænkelige situationer, den behøver ikke se poleret ud, og den behøver bestemt ikke kunne bruges af hundrede brugere på én gang. Den skal gøre én ting: overbevise et rum fuld af mennesker om at idéen virker, og at den er værd at investere i.

Det lyder enkelt. Det er det ikke. De fleste teams bruger den første halvdel af hackathon på at overbygge, fordi de tænker på det færdige produkt i stedet for på demonstrationen. Det er den fejl der koster flest timer og flest præmier.

En stærk hackathon-prototype kan demonstreres på 3 til 5 minutter. Den løser ét konkret problem. Den bruger rigtige data, eller data der ser rigtige ud. Og AI-komponenten er tydelig og forståelig for et ikke-teknisk publikum.

Formlen der virker

Den vigtigste indsigt fra vores erfaring med AI hackathons er så enkel, at de fleste teams afviser den i starten: hold det simpelt.

Den formel vi anbefaler er: ét input, én AI-behandling, ét output.

Det betyder at prototypen modtager noget, lader AI gøre noget med det og viser resultatet. Intet mere. Et team der holder sig til denne formel, har typisk en fungerende prototype efter 10 til 14 timer og bruger resten af tiden på at gøre demo'en overbevisende.

Et konkret eksempel fra et af vores hackathons: et team fra en stor dansk detailkæde byggede et system der modtog kundeanmeldelser, lod AI kategorisere dem efter tema og sendte et dagligt overblik til butikschefer. Input: anmeldelser. AI-behandling: kategorisering og sammenfatning. Output: dagligt overblik på mail. Det tog ni timer at bygge. Det kørte i produktion seks uger efter hackathon.

Et andet eksempel: et HR-team byggede et system der tog en jobannonce og automatisk genererede et struktureret spørgeskema til kandidatsamtaler, tilpasset den specifikke rolle. Input: jobannonce. AI-behandling: analyse og spørgsmålsgenerering. Output: færdigt spørgeskema. Elleve timer fra start til demo. Er i dag i brug i hele organisationen.

Ingen af disse projekter var teknisk komplekse. De vandt fordi de løste et reelt problem på en måde der var tydelig for alle i rummet.

Hvem bygger hvad?

Et af de valg teams skal tage tidligt er, hvilke værktøjer de bruger. Her er tommelfingerreglen vi giver alle teams:

Ingen teknisk baggrund? Brug AI-chatværktøjer til at generere indhold, analyser og tekst, og brug automatiseringsværktøjer til at forbinde det hele. Ingen af disse kræver at man kan skrive kode. Et team med forretningsforståelse og god problemformulering kan bygge overraskende kraftfulde prototyper uden at røre en enkelt linje kode.

Lidt teknisk erfaring? AI-værktøjer som Claude kan generere en fungerende brugerflade direkte fra en beskrivelse. Man beskriver hvad man vil se, og AI bygger det. Resultatet ser professionelt ud og er klar til at vise frem.

Teknisk baggrund i teamet? Brug den til at bygge det bindeled der gør prototypen virkelig overbevisende, men hold arkitekturen enkel. De dygtigste udviklere i et hackathon er dem der aktivt vælger den enkle løsning og bruger den sparede tid på at gøre demo'en fejlfri.

Det afgørende er at matche ambitionsniveauet til de ressourcer teamet rent faktisk har. Et team af forretningsfolk der forsøger at bygge som udviklere, ender typisk med hverken en god prototype eller en god demo.

Hvad sker der time for time?

De fleste 48-timers hackathons følger et mønster vi genkender uanset branche og virksomhed:

De første to timer handler om at lande problemformuleringen. Hvilket problem skal løses? Hvem rammes? Hvad er det konkrete succeskriterium? Teams der bruger fuld tid her, vinder næsten altid sammenlignet med teams der skynder sig videre.

Time to til fire er idésortering. Ét klart koncept skal vælges. Ikke to, ikke "vi laver begge og ser hvad der er bedst." Ét. Fra dette punkt er al energi på den ene idé.

Time fire til tolv er byggeperioden. Den enkle formel skal fungere. Input virker. AI giver fornuftigt output. Outputtet vises. Ikke mere.

Time tolv til fireogtyve er finpudsning. Hvad ser galt ud? Hvad forvirrer? Er der situationer der går galt i demo'en? Brug rigtige data hvis muligt.

De sidste fireogtyve timer er præsentationsforberedelse. Ikke bygning. Teams der stadig tilføjer funktioner i den sidste halvdel fejler konsekvent ved præsentationen. Demo'en øves mindst to gange i fuld længde, med alt udstyr og i det rigtige rum.

De fejl der koster prototypen

Vi ser de samme fejl igen og igen:

For mange funktioner. Teams der prøver at demonstrere seks ting, demonstrerer ingen af dem overbevisende. Skær til. Byg ét centralt øjeblik der er uafviseligt stærkt.

Ingen testdata klar. En prototype der afhænger af live-data fra et produktionssystem, vil gå galt i demo'en. Alle stærke hackathon-prototyper har realistisk testdata klar fra starten, data der ser ægte ud og giver et imponerende output.

Generalprøven springes over. De teams der ikke har kørt demo'en fra ende til anden mindst to gange inden præsentationen, støder altid på noget der går galt under pres. Generalprøven er ikke valgfri.

Forkert ambitionsniveau. Et team af forretningsfolk der vælger den teknisk komplicerede løsning fordi den lyder mere imponerende, bruger halvdelen af tiden på at lære nye værktøjer. Den enkle løsning der virker fejlfrit er altid stærkere end den komplekse der hakker.

Hvad der afgør vinderen

Den prototype der vinder er sjældent den teknisk mest avancerede. Den vinder fordi problemet er forståeligt, løsningen er tydelig og demo'en er fejlfri.

Juryer og ledelse evaluerer ikke teknisk kompleksitet. De evaluerer om de tror på at dette kan løse et reelt problem, og om de kan forestille sig det i produktion. Det kræver klarhed, ikke kompleksitet.

48 timer er nok. Men kun hvis man er præcis på hvad man bygger, og holder fast i det enkle frem for det imponerende.