Hvorfor er det så dyrt at lave en app?
En app er dyr fordi den i praksis er mindst tre systemer der skal bygges og vedligeholdes: en iOS-app, en Android-app og en backend der gemmer data og styrer logikken. Derudover ses cirka 80 procent af arbejdet aldrig i brugerfladen: sikkerhed, fejlhåndtering, datalag og test. Du betaler for et system der virker, ikke for skærmbillederne.
En app ser lille ud: nogle skærmbilleder, nogle knapper. Alligevel koster selv enkle apps hundredtusindvis af DKK. Forklaringen er ikke at bureauer tager urimeligt meget for det, men at en app er mere system end det man ser, og at størstedelen af arbejdet ligger under overfladen. Her er hvorfor, og hvad du faktisk kan gøre ved prisen.
En app er mindst tre systemer
Det man i daglig tale kalder “en app”, er i praksis mindst tre produkter der bygges, testes og vedligeholdes:
- iOS-appen med Apples designsprog, regler og årlige OS-opdateringer.
- Android-appen med sine egne konventioner for brugerfladen og et langt mere broget udvalg af enheder den skal fungere på.
- Backend, serverdelen der gemmer data, håndterer konti, sender notifikationer og taler med andre systemer. Den ses aldrig, men uden den er appen en tom skal.
Cross-platform-teknologi som React Native lader iOS- og Android-appen dele det meste af koden, og det trækker omkostningen mærkbart ned. Men backend, test på platformene og processerne i app-butikkerne er der uanset hvad. Tre systemer betyder også tre ting der skal holdes i takt ved hver ændring, og det er grunden til at selv “en lille ændring” sjældent er lille.
80 procent af arbejdet ses ikke
Skærmbillederne du klikker på, er toppen af isbjerget. Cirka 80 procent af arbejdet i et app-projekt bruges på ting der aldrig ses i brugerfladen:
- Sikkerhed: kryptering, rettigheder, beskyttelse af personoplysninger, GDPR.
- Fejlhåndtering: hvad der sker når nettet forsvinder, serveren ikke svarer eller brugeren gør noget uventet. Den lykkelige vej er hurtig at bygge. Alle de ulykkelige tager tid.
- Datalag: strukturer der kan bære dagens funktioner og overleve morgendagens.
- Test: på forskellige enheder, OS-versioner, skærmstørrelser og netforhold.
- Integrationer: hver kobling til betalinger, MitID eller ERP-systemer er et lille projekt i sig selv.
Det er den samme forskel som mellem en messestand og et hus: Begge har vægge, men kun det ene skal stå i ti år, holde tæt og klare en inspektion.
App, hjemmeside eller webapp: sammenligningen
| Type | Typisk pris | Kompleksitet |
|---|---|---|
| Hjemmeside | 53.000–320.000 DKK | Ét system, viser indhold, ingen konti eller app-butikker |
| Webapp | 320.000 DKK–1,6 mio. DKK | Et til to systemer, login og logik, men én kodebase i browseren |
| Mobilapp | 270.000 DKK–5,3 mio. DKK | Tre systemer, to app-butikker, mange slags enheder, offline og notifikationer |
Sammenligningen forklarer prisforskellen bedre end noget tilbud: Det er ikke det samme der bygges. Den viser også hvorfor spørgsmålet “kan vi ikke starte med en webapp?” er helt rimeligt. Nogle gange er svaret ja.
Et scenarie: samme idé, tre prislapper
Lad os sige at du vil lade kunder booke tider hos dig. Som bookingside på nettet: måske 160.000 DKK. Som webapp med konti, historik og betaling: 430.000–740.000 DKK. Som mobilapp til iOS og Android med push-påmindelser og MitID: 740.000 DKK–1,3 mio. DKK. Funktionen “book tid” er den samme. Det der ændrer sig, er antallet af systemer, integrationer og platformskrav omkring den. Hvilket niveau der er det rigtige, afhænger af hvor ofte kunderne booker og hvor meget påmindelserne er værd for dig.
Det kan du påvirke
Prisen er ikke en naturlov. Fire løftestænger gør en reel forskel:
- Skær ned på scopet. Færre flows i version 1 er langt den største besparelse.
- Vælg cross-platform når appen ikke kræver det yderste af platformene.
- Brug færdige byggeklodser til login, betaling og analyse i stedet for at bygge dem selv.
- Kom med klare krav. Uklarhed betales altid med timer, og en kort forundersøgelse er billigere end at skifte mening midt i udviklingen.
Den femte løftestang er blødere, men reel: Vær en kunde der beslutter hurtigt. Projekter hvor beslutninger træffes inden for dage i stedet for uger, brænder færre timer af på ventetid, omarbejde og møderækker. Brugt rigtigt kan disse valg halvere en slutregning uden at produktet føles billigt. Hvordan AI-assisteret udvikling ændrer regnestykket, kan du læse mere om på vores AI-side. Vil du vide hvad netop din idé bør koste? Kontakt os, så gennemgår vi den.
Ofte stillede spørgsmål
Hvorfor ikke bygge til kun én platform?
Det er ofte en klog måde at sænke omkostningen på, især i en første version. Du halverer arbejdet med app-butikkerne og dele af testen. Ulempen er at du lukker en stor del af markedet ude, så valget bør styres af hvor din målgruppe faktisk er.
Bliver appen billigere med cross-platform-udvikling?
Ja, som regel. Med et framework som React Native deles hovedparten af koden mellem iOS og Android, og det sænker både udviklings- og vedligeholdelsesomkostningerne sammenlignet med to native apps. Backend, test på begge platforme og arbejdet med app-butikkerne er der dog uanset teknologivalg.
Er en webapp et billigere alternativ?
Ofte, ja. En webapp har én kodebase, ingen gennemgang i app-butikkerne og enklere distribution. Prisen er dårligere adgang til push-notifikationer, sensorer og offlinetilstand, og at den ikke findes der hvor mange brugere leder: i app-butikkerne. Til interne værktøjer er webappen alligevel ofte det rigtige svar.
Bliver app-udvikling billigere med AI?
AI-værktøjer gør udviklere hurtigere, især på rutinekode og test, og det presser timetallet i visse faser. Men kravarbejdet, arkitekturen, integrationerne og ansvaret for at det hele virker sammen er der stadig. Regn med at AI i højere grad påvirker hvor timerne lægges, end at den fjerner dem.
Hvad er den største enkeltstående omkostningsdriver i et app-projekt?
Omfanget, altså antallet af flows, roller og integrationer. Timepriserne varierer med tocifrede procentsatser mellem leverandører, men scopet kan variere med en faktor ti. Den der vil have prisen ned, skal derfor altid begynde med at skære i funktionslisten, ikke med at prutte om timeprisen.