Hver uke søker noen etter det samme.
Hva koster det å lage en mobilapp?
De finner et spenn. Vanligvis noe sånt som 15 000 til 500 000 dollar. Som er nøyaktig. Og nesten helt ubrukelig.
Her er saken: å spørre hva en mobilapp koster er som å spørre hva et hus koster.
Det avhenger helt av hva du vil bygge, og om du har funnet ut det ennå.
De fleste har ikke det. Det er ingen kritikk. Noen har en idé, et problem som skal løses, kanskje en konkurrent de vil slå. De vil ha et tall før de går videre. Det gir mening.
Men tallet finnes ikke ennå. Kostnadene for en mobilapp er ikke noe du kan slå opp. Det er resultatet av beslutninger, de fleste tatt før noen skriver en eneste linje kode.
Bedriftene som bygger apper innenfor budsjettet er ikke de heldige. De er de som stilte det riktige spørsmålet først.
Spørsmålet bak kostnaden
Før noen ærlig utviklingspartner kan fortelle deg hva appen din vil koste, trenger de å forstå hva du faktisk bygger.
Ikke generelt. Spesifikt.
Hvor mange typer brukere vil det være? Kobler appen seg til andre systemer? Må den fungere uten internett? Hva skjer når noe går galt?
Dette er ikke små detaljer. De er forskjellen mellom et prosjekt på 30 000 dollar og ett på 150 000 dollar.
Hva du faktisk betaler for
Når en utviklingspartner gir deg et tilbud på en mobilapp, tilbyr de ikke bare kode. De tilbyr arbeidet til et helt team: discovery, design, utvikling, testing og lansering, pluss alt som skal til for å holde det hele på rett spor.
Hver del koster noe. Og hver del avhenger av det som kom før.
Discovery er der du definerer hva som skal bygges og hvorfor. Å hoppe over dette er en av de vanligste grunnene til at prosjekter sprekker budsjettet. Hver time du ikke bruker på planlegging, koster gjerne tre timer i utvikling senere.
Design former hvordan brukere samhandler med appen. Dårlig design forblir ikke bare dårlig. Det bygges om senere, til full pris, som regel etter at ekte brukere allerede har støtt på problemene.
Så kommer utvikling, testing og utrulling. Hver fase legger seg oppå den forrige. Og problemer som oppdages tidlig er alltid billigere enn problemer som oppdages etter lansering. Det gjelder for hvert eneste prosjekt, uten unntak.
Hva som driver kostnaden opp eller ned
Funksjoner. Hver funksjon du legger til bringer mer enn sin egen utviklingstid. Den bringer grensetilfeller, testscenarier, avhengigheter og fremtidig vedlikehold. En enkel app med fem skjermbilder er et helt annet prosjekt enn en med betalinger, varsler, brukerroller og offline-modus, selv om begge høres ut som «bare en app».
Plattform. Å bygge separate apper for iOS og Android dobler omtrent kostnadene. Kryssplattform-rammeverk som React Native og Flutter kan redusere det betydelig, fordi én kodebase kjører på begge. For de fleste forretningsapper er dette et smart utgangspunkt.
Integrasjoner. Å koble til eksterne systemer, enten det er et CRM, en betalingsleverandør eller interne verktøy, tar alltid mer tid enn det ser ut til. API-er feiler, dokumentasjon er ufullstendig, og hver integrasjon må testes og vedlikeholdes.
Teamets plassering. Utviklingsrater varierer mye avhengig av hvor teamet holder til. Et erfarent team i Sentral- eller Øst-Europa koster vanligvis mindre enn et tilsvarende team i USA eller Vest-Europa. Det som ikke endrer seg, er kostnadene ved dårlig kommunikasjon og uklar scope, uavhengig av hvor teamet er.
Hvor tydelig prosjektet er definert. Dette er den viktigste faktoren. Prosjekter som starter uten en klar scope, sprekker jevnlig 40 til 80 prosent over budsjettet. Ikke fordi noen er uærlige. Men fordi et vagt utgangspunkt gir et vagt estimat, og et vagt estimat har ikke rom for de reelle beslutningene som dukker opp når arbeidet begynner.
Hva koster det egentlig i 2026?
De fleste forretningsapper lander et sted mellom 15 000 og 150 000 dollar.
Enklere apper med noen kjernefunksjoner og én plattform kan være klare på under tre måneder. Mer komplekse apper med flere brukerroller, en skikkelig backend og flere integrasjoner tar lengre tid og koster mer. Prosjekter på enterprise-nivå med krav til samsvar eller sanntid går enda lenger.
To selskaper kan beskrive det de vil ha med nesten de samme ordene og ende opp med helt forskjellige prosjekter. Og helt forskjellige regninger.
Hva AI har endret, og hva det ikke har
Mange antar at AI har gjort mobilapper billigere. Det er en rimelig antagelse. Verktøy er raskere, utviklere kan gjøre mer på kortere tid, og noen oppgaver som tidligere tok dager tar nå timer.
Men de fleste prosjektbudsjetter har ikke gått ned. Her er grunnen.
Når utviklingen går raskere, har omfanget en tendens til å vokse. Kunder ber om ting de ikke ville ha vurdert før. Et prosjekt på tre måneder forblir tre måneder, bare med dobbelt så mye innhold.
Det er ikke alltid en dårlig ting. Men det betyr at det å vite hva produktet ditt trenger å være i versjon én har blitt viktigere, ikke mindre. Jo lettere det er å legge til funksjoner, jo lettere er det å miste fokus.
AI har ikke endret spørsmålet du trenger å svare på før du begynner å bygge. Det har bare gjort kostnaden ved å ikke svare på det høyere.
Kostnadene de fleste tilbud ikke nevner
Vedlikehold. Planlegg å bruke omtrent 15 til 20 prosent av utviklingskostnadene hvert år bare for å holde appen i god stand. Det første året pleier å være høyere, fordi ekte brukere alltid finner ting som testing ikke fanget opp. iOS og Android oppdateres hvert år, og apper som ikke henger med begynner å feile.
Infrastruktur. Hosting og backend-kostnader kan variere fra 100 til 2 000 dollar eller mer per måned, avhengig av hvordan appen er bygget og hvor mange som bruker den. Dette er nesten aldri inkludert i utviklingstilbud.
Å nå brukerne. Å bygge appen er bare halvparten av jobben. Å nå menneskene som trenger den krever et eget budsjett. For de fleste nye forretningsapper bør du regne med å bruke 15 000 til 60 000 dollar det første året på app store-optimalisering, betalte annonser og innhold. Det dyreste utfallet er en app ingen finner.
Tilbake til spørsmålet
Det finnes et mønster som skiller prosjekter som avsluttes innenfor budsjettet fra de som ikke gjør det.
Det er ikke byrået, ikke teknologien, ikke native versus kryssplattform eller AI-verktøy versus tradisjonell utvikling.
Det er om de riktige spørsmålene ble besvart før arbeidet startet.
Hva bygger vi? For hvem? Hva inkluderer versjon én egentlig? Hvordan ser suksess ut på lanseringsdagen, ikke seks måneder senere.
Disse svarene er det som gjør et estimat om til et reelt tilbud.
Hos Rocksoft går vi gjennom dette før ethvert byggeprosjekt i en Discovery Workshop. Resultatet er en tydelig spesifikasjon: hva som bygges, i hvilken rekkefølge og med hvilke begrensninger. Noe konkret du kan ta med deg hvor som helst og få et reelt tall fra.
Prosjekter som starter på denne måten avsluttes nærmere budsjettet. Ikke på grunn av magi. Men fordi de vanskelige beslutningene tas før de blir kostbare.
Foretrekker du å se? Edwin går gjennom tallene i denne videoen.
