Så lang tid tager det reelt at bygge en app

“Hvor lang tid tager det?” er et af de første spørgsmål enhver appidé møder, og det ærlige svar er: Det kommer an på. Men det er muligt at give realistiske intervaller og at pege på hvad der styrer dem. Det meste af det der rykker en tidsplan, ligger nemlig ikke hos udviklerne, men hos kunden: hvor hurtigt beslutninger træffes, hvordan der gives feedback og hvornår indholdet kommer.

Tidslinjer efter projekttype

Intervallerne nedenfor dækker hele vejen: design, udvikling og test, frem til en app der er klar til at blive indsendt til gennemgang. De forudsætter at arbejdet glider uden lange pauser.

En enkel app har få skærmbilleder, login og indhold fra et enkelt API. En mellemkompleks app har egen backend, flere brugerroller, betaling og måske et par integrationer. En kompleks app har realtidsdata, tunge integrationer med ERP-systemer og høje sikkerhedskrav. Jo længere nede i tabellen, desto mere af tiden går til andet end ren kodning, først og fremmest test og koordinering.

En udbredt misforståelse er at tiden hovedsageligt går til kode. I virkeligheden tager design og test ofte lige så meget, og de mange små beslutninger undervejs vejer tungt. En app der “bare” skal bygges hurtigt, kan alligevel tage måneder hvis hver beslutning skal vente på svar.

Hvad der rykker tidsplanen

De fleste forsinkelser kan forudses, for de går igen fra projekt til projekt. Fire faktorer skiller sig ud:

• Beslutningstempo. Hver gang en beslutning trækker ud, opstår der dødtid. Et projekt hvor kunden svarer samme uge, går mærkbart hurtigere end et hvor svarene tager uger.
• Feedback. Samlet og tydelig feedback driver projektet fremad. Spredt, modstridende eller konstant revurderet feedback skaber omarbejde der æder tid.
• Indhold. Tekster, billeder og data som appen har brug for, er overraskende ofte en flaskehals. Er indholdet ikke klar, kan appen heller ikke blive det.
• Voksende omfang. Hvert “kan vi også få …” der tilføjes efter start, rykker planen. Det er den mest almindelige årsag til at tidsplaner skrider.

Det trøstende er at kunden selv styrer det meste. Et klart billede af kravene fra begyndelsen, hurtige beslutninger og indhold til tiden forkorter tidsplanen mere end nogen teknisk optimering. At sætte flere udviklere på hjælper derimod sjældent i et lille projekt fordi flere personer også kræver mere koordinering.

Regn app-butikkernes gennemgang med

Et trin der ofte bliver glemt i planlægningen, er at appen skal gennemgås af Apple og Google før den bliver synlig i butikkerne. Gennemgangen tager oftest fra et døgn til nogle dage, men der er ingen garanti for at den går hurtigt. En app kan blive afvist og skulle rettes før den bliver godkendt, og det lægger en ekstra runde til.

Derfor skal gennemgangen med i tidsplanen, med margin. Det gælder især hvis lanceringen er knyttet til en dato, en kampagne eller et event. At planlægge som om godkendelsen kommer på en dag er at bygge unødig stress ind i slutfasen, netop når alt andet også skal gå op.

Et konkret regneeksempel

Lad os sige at du vil lancere en mellemkompleks bookingapp til efteråret. Udviklingen er anslået til seks måneder inklusive design og test. Så kan du ikke starte i marts og regne med lancering i september uden margin. Læg tid til gennemgang oveni og en buffer for at beslutninger og indhold indimellem trækker ud, og du bør snarere starte i februar for at lande sikkert. Pointen: Planlæg baglæns fra lanceringsdatoen, med gennemgang og buffer regnet med, i stedet for at antage at alt kører som på skinner.

Den bedste måde at holde en tidsplan på er at begynde med et klart grundlag. Under vores ydelser kan du læse mere om hvordan et forprojekt lægger grunden. Du kan også kontakte os med din idé, så giver vi et realistisk bud på tidsforbruget for netop den.