Hvor lang tid tager det at lave en app?

Kort svar

En enkel første version af en app, en såkaldt MVP, tager typisk et par måneder fra idé til App Store. En større app med betaling, mange skærmbilleder og integrationer til eksisterende systemer kan tage et halvt år eller mere. Selve godkendelsen hos Apple går som regel hurtigt: Apple skriver, at App Review typisk gennemgår mindst halvdelen af indsendelserne på under 24 timer og 90 procent på under 48 timer. Det, der afgør tidsplanen, er omfanget, antallet af integrationer, hvor hurtigt der træffes beslutninger, og om appen skal på både iOS og Android. Regner du også på prisen, så se vores guide om hvad det koster at lave en app.

Hvorfor der ikke findes ét svar

At spørge, hvor lang tid en app tager, er lidt som at spørge, hvor lang tid det tager at bygge et hus. Et sommerhus og et etagebyggeri er begge huse. En app med fem skærmbilleder og ingen login er noget helt andet end en app med brugerkonti, betaling, push-beskeder og en kobling til virksomhedens lagersystem.

Derfor er det vigtigste spørgsmål ikke “hvor lang tid”, men “hvad skal første version kunne”. Når det er besluttet, kan tidsplanen estimeres med rimelig sikkerhed. Indtil da er ethvert tal et gæt.

Faserne og deres varighed

Et typisk app-projekt går gennem de samme faser, uanset størrelse. Varigheden af hver fase skalerer med omfanget.

Fase	Hvad der sker	Typisk varighed for en MVP
Afklaring	Mål, brugere, funktioner, prioritering	1 til 3 uger
Design	Brugerrejser, skærmbilleder, prototype	2 til 6 uger
Udvikling	App, server og integrationer bygges	6 til 16 uger
Test	Fejlretning på rigtige enheder	2 til 4 uger, delvist parallelt
Indsendelse og godkendelse	App Store og Google Play	Dage til et par uger

Tallene er planlægningsintervaller for en afgrænset første version, ikke løfter. Faserne overlapper også i praksis: design af senere skærmbilleder kan fortsætte, mens udviklingen af de første er i gang, og test sker løbende, ikke kun til sidst.

Afklaring

Afklaringsfasen er den korteste og den vigtigste. Her besluttes, hvem appen er til, hvilket problem den løser, og hvilke funktioner der hører til første version. Et projekt, der springer denne fase over, betaler for det senere i form af ændringer midt i udviklingen, som er langt dyrere og langsommere.

Design

Designfasen omsætter beslutningerne til skærmbilleder og en klikbar prototype. Apples Human Interface Guidelines beskriver, hvordan en iOS-app forventes at opføre sig, og et design, der følger dem, er både hurtigere at bygge og lettere at få godkendt. Prototypen er også det billigste sted at opdage, at en idé ikke virker: at ændre en skitse tager minutter, at ændre færdig kode tager dage.

Udvikling

Udvikling er den længste fase. Her bygges selve appen, serveren, der gemmer data, og koblingerne til andre systemer. Det er også her, de fleste overraskelser opstår, især i integrationer. Et lagersystem eller et bookingsystem, der skal tale med appen, har ofte begrænsninger, som ingen kendte på forhånd.

Test og godkendelse

Test sker på rigtige telefoner, ikke kun i simulatoren, fordi fejl ofte kun viser sig på bestemte enheder eller iOS-versioner. Apples TestFlight gør det muligt at dele testversioner med en gruppe testere, før appen udgives, og det er en god idé at lade nogle af de kommende brugere prøve appen her. Deres feedback fanger ofte de misforståelser, som udviklerne selv er blinde for. Derefter indsendes appen.

App Store og Google Play: den sidste strækning

Mange undervurderer den sidste strækning, fordi den afhænger af andre end en selv.

App Store. Apples gennemgang går typisk hurtigt, men en afvisning koster tid, fordi fejlen skal rettes og appen indsendes igen. Apple oplyser, at over 40 procent af de uløste problemer handler om retningslinje 2.1, appens fuldstændighed, som dækker nedbrud, pladsholderindhold og ufuldstændige oplysninger. En app, der virker færdig ved første indsendelse, sparer derfor ofte flere dage. Du skal også have et medlemskab i Apple Developer Program, og tilmeldingen kan tage tid, især for virksomheder, der skal verificeres.

Google Play. Her er der en regel, mange ikke kender. Ifølge Google skal udviklere med personlige konti oprettet efter 13. november 2023 køre en lukket test med mindst 12 testere, der har været tilmeldt uafbrudt i mindst 14 dage, før de kan søge om adgang til produktion. Det betyder mindst to ugers ekstra kalendertid, som skal planlægges ind. Google skriver desuden, at nogle apps får en udvidet gennemgang, som kan tage op til syv dage eller længere i særlige tilfælde.

Et eksempel

Forestil dig en app til en kæde af fysioterapiklinikker i Aarhus. Patienter skal kunne logge ind, booke tider, få påmindelser og se deres øvelser. Bookingen skal kobles til klinikkernes eksisterende bookingsystem.

Afklaringen tager et par uger, fordi klinikkerne skal blive enige om, hvad første version skal indeholde. Øvelsesbiblioteket flyttes til version to. Designet tager omkring en måned, inklusive en prototype, som et par patienter afprøver. Udviklingen tager et par måneder, hvoraf en stor del går med koblingen til bookingsystemet. Test og godkendelse tager et par uger mere. Samlet er appen i App Store efter cirka et halvt år, hvoraf noget af tiden er ventetid på beslutninger og adgange fra kundens side.

Havde øvelsesbiblioteket været med i første version, var tidsplanen blevet væsentligt længere. Det er sådan de fleste tidsplaner reelt styres: ved at vælge, hvad der ikke skal med.

Hvad der forlænger og forkorter tidsplanen

Forlænger	Forkorter
Uklare krav og mange ændringer undervejs	En skarp, prioriteret liste over funktioner
Mange integrationer med eksisterende systemer	Få eller ingen integrationer
Både iOS og Android fra start	Én platform først
Langsomme beslutninger og mange beslutningstagere	Én ansvarlig hos kunden med mandat
Manglende indhold, tekster og adgange	Indhold og adgange klar ved start
Specialdesign af alle elementer	Standardkomponenter fra platformen

Mange forsinkelser opstår ikke i koden, men mellem beslutningerne. En uge, hvor udviklerne venter på svar om en funktion, er en tabt uge, også selvom ingen har lavet fejl.

Det kan du selv gøre for at holde tidsplanen

En stor del af tidsplanen ligger faktisk hos kunden, ikke hos udviklerne. Disse punkter gør den største forskel:

1. Udpeg én ansvarlig. Én person, der kan træffe beslutninger om funktioner og design, og som svarer inden for en dag eller to.
2. Skriv ned, hvad første version ikke skal kunne. En liste over fravalg er lige så vigtig som listen over funktioner, fordi den beskytter mod, at omfanget vokser undervejs.
3. Hav indhold klar. Tekster, billeder, priser, vilkår og privatlivspolitik tager ofte længere tid at skaffe end forventet.
4. Skaf adgange tidligt. Adgang til eksisterende systemer, testmiljøer og dokumentation for integrationer bør være på plads, før udviklingen starter.
5. Opret konti i virksomhedens navn. Apple Developer-medlemskab og Google Play-konto bør oprettes tidligt, fordi verificeringen kan tage tid, og fordi kontiene skal ejes af virksomheden, ikke af bureauet.
6. Planlæg testere. Find de personer, der skal teste appen, i god tid, især hvis Googles krav om en lukket test med mindst 12 testere gælder for dig.

Ingen af punkterne kræver teknisk viden, men tilsammen kan de spare uger.

Efter lanceringen: version to og opdateringer

Lanceringen er ikke slutningen på tidsplanen. De første uger efter udgivelsen kommer der næsten altid små rettelser, fordi rigtige brugere gør ting, ingen testede. Derefter følger version to med de funktioner, der blev skubbet ud af første version, nu prioriteret efter, hvordan appen faktisk bliver brugt.

Opdateringer går typisk hurtigere end den første udgivelse, fordi fundamentet er på plads, og fordi app-butikkerne allerede kender appen. Men de skal stadig gennem Apples og Googles gennemgang. Det er derfor klogt at samle rettelser i planlagte udgivelser frem for at sende en ny version ind hver gang, en lille fejl bliver fundet. Vedligeholdelse fortsætter også i årene efter, og vores guide om hvad det koster at vedligeholde en app forklarer, hvad du skal regne med.

Hurtigere uden at gå på kompromis med kvaliteten

Den mest effektive måde at få en app hurtigere ud på, er at bygge mindre. Det er hele idéen bag en MVP: at udgive den mindste version, der løser kerneproblemet for brugerne, og lære af den rigtige brug, før man bygger videre. Vores svenske guide forklarer hvad en MVP er.

Andre gode genveje er at bruge platformens standardkomponenter i stedet for at designe alt fra bunden, at starte på én platform, og at have indhold og adgange klar, før udviklingen begynder.

Den genvej, der næsten aldri virker, er at presse udviklerne til at gøre det samme arbejde hurtigere. Det giver typisk flere fejl, flere afvisninger og en længere vej til lancering, ikke en kortere.

Hvorfor meget korte tidsplaner bør vække mistanke

Lover et bureau en komplet app med login, betaling og integrationer på få uger, er der god grund til at spørge ind. Enten er omfanget mindre end du tror, eller også bliver der sparet på test og kvalitet. Begge dele viser sig senere, ofte som afvisning i App Store eller fejl hos de første brugere.

Hos AJBU estimerer vi først, når første versions omfang er afklaret, og vi viser tidsplanen fase for fase, så det er tydeligt, hvor tiden går. Du kan se eksempler på apps, vi har bygget, under vores arbejde.

Når det går hurtigere end forventet

Nogle apps kan faktisk laves hurtigt. En intern app til få medarbejdere, uden betaling og uden integrationer, eller en simpel kampagneapp kan være klar på væsentligt kortere tid end tallene ovenfor. Det samme gælder, hvis designet allerede findes, eller hvis appen bygger videre på en eksisterende platform. Det vigtigste er at kende sin egen app: jo færre bevægelige dele, desto kortere tidsplan.