Hvorfor er det så dyrt å utvikle en app?
En app er dyr fordi den i praksis er minst tre systemer som skal bygges og vedlikeholdes: en iOS-app, en Android-app og en backend som lagrer data og styrer logikken. I tillegg vises omtrent 80 prosent av arbeidet aldri i grensesnittet (sikkerhet, feilhåndtering, datalagring og testing). Du betaler for et system som fungerer, ikke for skjermbildene.
En app ser liten ut: noen skjermbilder, noen knapper. Likevel koster selv enkle apper hundretusenvis av kroner. Forklaringen er ikke at byråer tar seg grovt betalt. Det er at en app er mer system enn det som vises, og at mesteparten av arbeidet ligger under overflaten. Her er hvorfor, og hva du faktisk kan gjøre med prisen.
En app er minst tre systemer
Det som i dagligtale kalles «en app», er i praksis minst tre produkter som bygges, testes og vedlikeholdes:
- iOS-appen: med Apples designspråk, regler og årlige OS-oppdateringer.
- Android-appen: med sine egne grensesnittkonvensjoner og en langt mer uensartet flora av enheter den må fungere på.
- Backend: serverdelen som lagrer data, håndterer kontoer, sender varsler og snakker med andre systemer. Den vises aldri, men uten den er appen et skall.
Cross-platform-teknologi (kryssplattform) som React Native lar iOS- og Android-appene dele det meste av koden, noe som demper kostnaden kraftig, men backend, testing per plattform og prosessene i appbutikkene består uansett. Tre systemer betyr også tre ting som skal holdes synkronisert ved hver endring, og det er grunnen til at selv «en liten endring» sjelden er liten.
80 prosent av arbeidet vises ikke
Skjermbildene du klikker på, er toppen av isfjellet. Omtrent 80 prosent av arbeidet i et apputviklingsprosjekt går med til ting som aldri vises i grensesnittet:
- Sikkerhet: kryptering, tilganger, vern av personopplysninger, GDPR.
- Feilhåndtering: hva som skjer når nettet forsvinner, serveren ikke svarer eller brukeren gjør noe uventet. Happy path, der alt går som det skal, er rask å bygge. Alle avvikene fra den tar tid.
- Datalagring: strukturer som takler dagens funksjoner og overlever morgendagens.
- Testing: på ulike enheter, OS-versjoner, skjermstørrelser og nettverksforhold.
- Integrasjoner: hver kobling til betalinger, BankID eller ERP-systemer er et eget lite prosjekt.
Det er den samme forskjellen som mellom en messestand og et hus: Begge har vegger, men bare det ene skal stå i ti år, holde tett og bestå en kontroll.
App, nettside eller webapp: sammenligningen
| Type | Typisk kostnad | Kompleksitet |
|---|---|---|
| Nettside | 62 000–370 000 kr | Ett system, viser innhold, ingen kontoer eller appbutikker |
| Webapp | 370 000 kr–1,9 millioner kr | Ett til to systemer, innlogging og logikk, men én kodebase i nettleseren |
| Mobilapp | 310 000 kr–6,2 millioner kr | Tre systemer, to appbutikker, mange enhetstyper, offline og varsler |
Sammenligningen forklarer prisforskjellen bedre enn noe tilbud: Det er ikke det samme som bygges. Den viser også hvorfor spørsmålet «kan vi ikke begynne med en webapp?» er helt berettiget. Noen ganger er svaret ja.
Et scenario: samme idé, tre prislapper
La oss si at du vil la kunder bestille time hos deg. Som bookingside på nettet: kanskje 190 000 kr. Som webapp med kontoer, historikk og betaling: 500 000–870 000 kr. Som mobilapp for iOS og Android med pushpåminnelser og sikker innlogging: 870 000 kr–1,5 millioner kr. Funksjonen «bestille time» er den samme. Det som endres, er antall systemer, integrasjoner og plattformkrav rundt den. Hvilket nivå som er riktig, avhenger av hvor ofte kundene bestiller, og hvor mye påminnelsene er verdt for deg.
Dette kan du påvirke
Prisen er ingen naturlov. Fire grep gjør virkelig forskjell:
- Slank omfanget. Færre brukerreiser i versjon 1 er den klart største besparelsen.
- Velg cross-platform når appen ikke krever det ytterste av plattformene.
- Bruk ferdige byggeklosser for innlogging, betaling og analyse i stedet for å bygge alt selv.
- Kom med tydelige krav. Uklarhet betales alltid med timer, og en kort forstudie er billigere enn å ombestemme seg underveis.
Det femte grepet er mykere, men reelt: Vær en kunde som bestemmer seg raskt. Prosjekter der beslutninger tas i løpet av dager i stedet for uker, bruker færre timer på venting, omarbeiding og møterekker. Brukt riktig kan disse valgene halvere sluttregningen uten at produktet føles billig. Hvordan AI-assistert utvikling endrer regnestykket, kan du lese mer om på AI-siden vår. Vil du vite hva akkurat din idé bør koste? Ta kontakt, så går vi gjennom den.
Ofte stilte spørsmål
Hvorfor ikke bygge for bare én plattform?
Det er ofte en klok måte å redusere kostnaden på, særlig for en første versjon. Du halverer arbeidet mot appbutikkene og deler av testingen. Ulempen er at du stenger ute brukerne på den andre plattformen, så valget bør styres av hvor målgruppen din faktisk er.
Blir appen billigere med cross-platform-utvikling?
Ja, som regel. Med et rammeverk som React Native deles hoveddelen av koden mellom iOS og Android, noe som reduserer både utviklings- og vedlikeholdskostnaden sammenlignet med to native apper. Backend, testing på begge plattformene og arbeidet mot appbutikkene gjenstår uansett teknologivalg.
Er en webapp et billigere alternativ?
Ofte, ja. En webapp har én kodebase, ingen gjennomgang i appbutikkene og enklere distribusjon. Prisen er dårligere tilgang til pushvarsler, sensorer og offlinemodus, og at appen ikke ligger der mange brukere leter, nemlig i appbutikkene. For interne verktøy er webappen likevel ofte riktig svar.
Blir apputvikling billigere med AI?
AI-verktøy gjør utviklere raskere, særlig på rutinekode og tester, og det presser ned timetallet i enkelte faser. Men kravarbeid, arkitektur, integrasjoner og ansvaret for at alt fungerer sammen, består. Regn med at AI påvirker hvor timene brukes mer enn at den fjerner dem.
Hva er den største enkeltstående kostnadsdriveren i et apputviklingsprosjekt?
Omfanget, altså antall brukerreiser, roller og integrasjoner. Timeprisene varierer med titalls prosent mellom leverandører, men omfanget kan variere med en faktor ti. Den som vil få ned prisen, bør derfor alltid begynne med å slanke funksjonslisten, ikke med å prute på timeprisen.