Hva koster det å lage en app i Norge?

Det ærlige svaret er «det kommer an på» — men det er et ubrukelig svar. Her er hva prisen faktisk består av, og hva som avgjør om du havner i nedre eller øvre ende.

Spør du tre utviklingshus om hva appen din koster, får du tre vidt forskjellige tall — og alle tre kan være riktige. Det er ikke fordi noen prøver å lure deg. Det er fordi «en app» kan bety alt fra et skjema med en database bak, til et system som håndterer kart, sanntidsdata og offline-drift på en telefon uten dekning.

Vi har bygget begge deler. Her er hva vi har lært om hvor pengene faktisk går, slik at du kan stille bedre spørsmål — også til oss.

Prisen er timer, ikke lisenser

Nesten hele kostnaden ved å lage en app er mennesketimer. Selve teknologien er i praksis gratis: rammeverkene er åpen kildekode, og driften av en app med noen tusen brukere koster typisk mindre i måneden enn et middagsbesøk. Det du betaler for, er tiden det tar å bestemme hva appen skal gjøre, bygge det, teste det, og fikse det som ikke virker.

Det betyr at det viktigste kostnadsspørsmålet ikke er «hvilken teknologi», men «hvor mye skal den gjøre». Hver funksjon du legger til koster ikke bare tiden det tar å bygge den — den koster også tid i testing, i vedlikehold, og i alle de fremtidige funksjonene som må ta hensyn til den.

De fire tingene som driver prisen

Erfaringsmessig er det fire faktorer som avgjør om et prosjekt lander lavt eller høyt. De henger sammen, men de er verdt å vurdere hver for seg.

• Antall plattformer. En app kun for iPhone er vesentlig rimeligere enn iPhone og Android samtidig. Skal den også finnes i nettleseren, er det en tredje jobb. Det er ofte klokt å starte med én plattform, lære av ekte brukere, og utvide etterpå.
• Hvor data kommer fra. Bruker appen bare sine egne data, er det enkelt. Skal den hente fra eksterne kilder — kartverk, værtjenester, regnskapssystemer, betalingsløsninger — må hver kilde tolkes, feilhåndteres og holdes i live når kilden endrer seg.
• Om den må virke uten nett. Offline-støtte er den enkeltfunksjonen som oftest undervurderes. Det betyr at data må lagres lokalt, synkroniseres når nettet er tilbake, og håndtere at to enheter har endret det samme mens de var frakoblet.
• Om andre skal logge inn. Så snart flere brukere og bedrifter deler samme system, må du håndtere roller, tilganger og at ingen ser andres data. Det er sikkerhetsarbeid som ikke synes i grensesnittet, men som er helt avgjørende.

Hva du får for pengene i hver ende

Grovt sagt finnes det tre nivåer. I den nedre enden ligger en fokusert app som gjør én ting godt: den henter data fra ett sted, viser det pent, og lar brukeren gjøre noen få handlinger. Den kan bygges på uker, ikke måneder, og er ofte den riktige måten å teste om ideen din holder.

I midten ligger de fleste reelle produkter: innlogging, flere brukertyper, data som skal synkroniseres, betaling, og et grensesnitt som tåler at folk bruker det hver dag. Her snakker vi måneder med utvikling.

I den øvre enden ligger systemer som Oystr — der selve kjernen i produktet er teknisk krevende, og der feil har konsekvenser ute i den virkelige verden. Slike prosjekter måles i kvartaler, og de blir aldri helt ferdige, fordi datakildene og plattformene under dem er i konstant bevegelse.

Kostnaden folk glemmer: drift

Den vanligste feilen vi ser, er at hele budsjettet går til å bygge appen, og ingenting settes av til å ha den. En app er ikke et bilde du henger på veggen. Apple slipper ny iOS hvert år, datakilder endrer format, sikkerhetshull dukker opp i biblioteker du bruker, og brukerne dine finner ting du ikke tenkte på.

Regn med at drift og videreutvikling koster en betydelig andel av den opprinnelige utviklingen, hvert år. Det høres dyrt ut helt til du sammenligner det med alternativet: en app som gradvis slutter å virke, og som til slutt må bygges på nytt fra bunnen.

Slik får du mest for budsjettet

• Start smalt. Finn den ene tingen appen absolutt må gjøre, bygg den skikkelig, og la resten vente til ekte brukere har fortalt deg hva de savner.
• Vær tydelig på hvem den er for. En app for alle blir en app for ingen — og den blir dyr, fordi hver ny brukergruppe drar med seg nye krav.
• Velg ett team som eier hele løpet. Splittes design, utvikling og drift på flere leverandører, går mye tid til koordinering i stedet for produkt.
• Be om å se noe tidlig. Fungerende programvare etter noen uker sier mer enn en kravspesifikasjon på femti sider.

Hva vi gjør annerledes

Vi har bygget og driftet våre egne produkter i årevis, og levd med hver eneste snarvei vi tok. Det former hvordan vi bygger for andre: kjedelig og holdbart fremfor imponerende og skjørt, fordi vi vet hvem som får telefonen når noe knekker. Og siden vi tar eierandel i stedet for honorar, er det vår egen framtid som står på spill hvis vi bygger noe skjørt.

Vi fakturerer ikke selv — vi går inn som partner mot en eierandel. Men tallene over er verdt å kjenne uansett hvem du bygger med, og lurer du på hva ideen din faktisk krever, er det bare å ta kontakt.