Prototype af en app: test idéen, før du betaler for hele appen

Hvad en prototype app koster i Danmark

En prototype app er den billigste version af din idé, der stadig kan vises til en rigtig bruger. Den er ikke et produkt. Den er et værktøj til at finde ud af, hvad produktet skal være, før du betaler for at bygge det. Overblikket over hele forløbet, fra platformvalg til hvem der bygger, står i guiden til app udvikling. Her handler det kun om det første skridt.

Danske udbydere er bemærkelsesværdigt enige om prisen på det første skridt, og bemærkelsesværdigt uenige om alt, hvad der kommer bagefter. Tabellen er samlet fra deres egne prissider og tjekket 3. november 2026.

Leverance	Pris	Hvad der er med
Klikbar prototype	20.000-40.000 kr.	Rigtigt design og klikbare skærme. Ingen kode, kan ikke lanceres og bruger ikke kamera eller GPS.
MVP hos lavprisudbyder	45.000-90.000 kr.	100-200 timer til 450 kr. Kun de kernefunktioner, der skal til for at få feedback fra brugere.
Enkel webapp	20.000-80.000 kr.	Statisk indhold, én brugertype, ingen integrationer. Kører i browseren.
Mindste app-projekt hos et etableret bureau	135.000-180.000 kr.	Cirka 150 timer til 900-1.200 kr. i timen.
Forretningsapp til iOS og Android	150.000-600.000 kr.	Flere brugerroller, integrationer og eget design.

Prototype og MVP er fra Tiblos prisside. Webapp og forretningsapp er fra Sanocasts prisguide, og bureautallet er regnet ud fra timeantal og timepris i Little Giants' artikel. Little Giants skriver i øvrigt selv, at et pålideligt estimat kræver en prototype og en kravspecifikation først. Det er hele pointen. Prototypen er det, der gør resten af tilbuddene sammenlignelige.

Læg mærke til forholdet. En klikbar prototype koster typisk mellem 3 % og 27 % af en forretningsapp. Hvis den fjerner bare én funktion, du ellers ville have bestilt, har den betalt sig selv hjem. Den fulde prisgennemgang med timepriser og butiksgebyrer står i artiklen om app udvikling pris.

Tre slags prototype til tre forskellige spørgsmål

Når du vil have lavet en app, er det første spørgsmål ikke, hvordan den skal se ud. Det er, hvad du er mest usikker på. Ordet prototype dækker over tre ting, og de svarer på hver sit spørgsmål.

• Klikbar prototype. Skærme tegnet i et designværktøj og koblet sammen, så man kan trykke sig igennem. Svarer på: forstår brugerne flowet, og finder de det, de leder efter? Den kan ikke svare på, om noget virker teknisk.
• Teknisk proof of concept. Et stykke kode, der beviser, at den svære del kan lade sig gøre. Typisk en integration til et eksisterende system, et stykke hardware eller en datakilde, man ikke selv styrer. Svarer på: kan det bygges, og hvad koster den del?
• MVP. En rigtig, men skrabet app, som rigtige brugere bruger i deres hverdag. Svarer på: vil nogen bruge den, igen og igen?

Den mest almindelige fejl, jeg ser, er at bestille den forkerte af de tre. Ligger usikkerheden i en integration til jeres ERP, hjælper det ikke at teste flotte skærme med fem brugere. Ligger usikkerheden i, om sælgerne overhovedet vil åbne appen, hjælper det ikke at bevise, at integrationen virker.

Hvad AI har ændret ved prototypen

Det er her, AI har flyttet mest i app-projekter. Værktøjer, der laver fungerende skærme ud fra en beskrivelse i almindeligt sprog, har gjort afstanden mellem en klikbar prototype og en fungerende prototype meget kortere. Flere af dem kan prøves gratis. I mine egne projekter betyder det, at en første version, man kan trykke rundt i på sin egen telefon, kan stå på få dage i stedet for et par uger.

Det har to konsekvenser for dig som køber. Den gode: du kan få testet flere varianter for de samme penge, fordi det er billigt at bygge om. Den farlige: en AI-bygget prototype ser færdig ud. Den har rigtige knapper og rigtige data, og det er fristende at sige, at den bare skal sættes i drift. Men en prototype er bygget til at blive smidt ud. Den har sjældent ordentlig sikkerhed, fejlhåndtering, adgangsstyring eller test, og det er netop de dele, der koster pengene i en rigtig app.

Aftal derfor fra start, om prototypens kode skal genbruges eller kasseres. Begge dele kan være rigtigt. Det forkerte er at finde ud af det bagefter.

Sådan tester du prototypen: fem brugere ad gangen

En prototype, ingen har testet, er bare en dyr tegning. Den gode nyhed er, at testen er billig. Nielsen Norman Group har i mange år anbefalet at teste med fem brugere, fordi fem brugere i deres model finder omkring 85 % af brugervenlighedsproblemerne. Har du råd til 15 testpersoner, er rådet at køre tre runder med fem i stedet for én stor: test, ret, test igen.

Sådan gør du i praksis:

1. Find fem personer, der ligner de rigtige brugere. Ikke kolleger, der kender idéen, og ikke din familie.
2. Giv dem en opgave, ikke en rundvisning. "Bestil en tid til næste tirsdag" fortæller dig mere end "hvad synes du om forsiden?"
3. Sig så lidt som muligt, og skriv ned, hvor de går i stå.
4. Ret det, tre eller flere af dem faldt over, og test igen med fem nye.

Bemærk at fem brugere er til at finde problemer, ikke til at måle noget. NN/g skriver selv, at reglen gælder kvalitative test. Vil du vide, hvor mange der vil betale, er det MVP'en, der skal svare.

Skal appen i Google Play fra en ny personlig udviklerkonto, kommer der i øvrigt en test, du ikke kan forhandle dig ud af: Google kræver en lukket test med mindst 12 testere i 14 sammenhængende dage, før appen må komme i produktion. Har du allerede fem gode testpersoner fra prototypen, har du en del af dem.

Det skal stå i tilbuddet på en prototype

En prototype til fast pris er let at sammenligne, hvis tilbuddene beskriver det samme. Kræv at disse punkter står på skrift:

• Hvilken slags prototype. Klikbar, teknisk eller MVP, og hvilket spørgsmål den skal besvare.
• Omfang. Hvor mange skærme eller flows, og hvilke der bevidst er udeladt.
• Testrunder. Hvor mange runder med brugere, og hvem der finder testpersonerne.
• Leverancen bagefter. En prioriteret funktionsliste og et estimat på den rigtige app i faser. Uden det har du betalt for skærme, ikke for en beslutning.
• Ejerskab. Designfiler og eventuel kode overdrages til jer, så I kan tage prototypen med til en anden leverandør.
• Genbrug. Om koden er tænkt som fundament for appen eller som noget, der kasseres.

Hvornår du kan springe prototypen over

Der er situationer, hvor prototypen er spild. Hvis appen er en kendt type, for eksempel en simpel booking eller en intern liste, er flowet allerede testet af millioner af brugere i andre apps. Hvis en kunde eller et udbud har lagt kravene fast i detaljer, er der ikke meget at teste. Og hvis budgettet til hele løsningen ligger tæt på prisen for en prototype, så byg en enkel webapp direkte og test den i stedet.

I alle andre tilfælde er regnestykket enkelt. Du skal lave en app, og den største risiko er ikke, at den bliver for dyr at bygge. Det er, at du bygger noget, ingen bruger. En prototype til 20.000-40.000 kr. er den billigste forsikring mod det, der findes.