Enkel app: 150 000–350 000 NOK
Én plattform eller enkel cross-platform-løsning, få skjermer, ingen eller én enkel integrasjon. Typisk en MVP for å validere en idé eller en intern app med begrenset funksjonalitet.
Vår apputvikling-side gir deg en kort oversikt over pris. Her går vi i dybden: prisdrivere, konkrete intervaller per kompleksitetsnivå, fastpris vs. timepris, og de skjulte kostnadene de fleste glemmer å budsjettere for.
Om du har lest vår apputvikling-side, har du sett det korte svaret: en app koster typisk mellom 150 000 og 1 500 000+ NOK, avhengig av kompleksitet. Det svaret er riktig, men det sier ikke så mye om hvorfor spennet er så stort, eller hvor akkurat ditt prosjekt havner i det. Denne siden er skrevet for å fylle det gapet — et reelt dypdykk i prisdriverne, med konkrete tall og resonnementer du kan bruke til å budsjettere realistisk.
Prisen på en app bestemmes ikke av én faktor, men av summen av flere valg: hvor mange plattformer appen skal fungere på, hvor mange integrasjoner mot andre systemer som trengs, hvor mye av funksjonaliteten som er unik versus standard, og hvilket sikkerhets- og driftsnivå virksomheten krever. To apper som «ser like enkle ut» utenfra kan koste helt forskjellig fordi den ene har et komplekst regelverk under overflaten og den andre ikke har det.
Vi har priset og levert apper i hele spennet fra enkle MVP-er til komplekse plattformer med tunge integrasjoner, og mønsteret er tydelig: prosjekter som sprekker i budsjett gjør det sjelden fordi utviklingen var «dyrere enn normalt», men fordi scope ikke var tydelig avklart før arbeidet startet, eller fordi drift og vedlikehold etter lansering aldri ble budsjettert inn. Resten av denne siden går gjennom hva som faktisk driver prisen, realistiske intervaller for norske prosjekter, og hvordan du unngår de vanligste kostnadsfellene.
Før du kan sette et realistisk budsjett, må du forstå hvilke valg som faktisk flytter prisen mest. Dette er ikke en uttømmende liste, men de faktorene som i praksis skiller et rimelig prosjekt fra et dyrt et.
Antall plattformer: en app som bare skal fungere på iOS eller Android koster mindre enn en som skal dekke begge — med mindre du velger cross-platform-teknologi, som reduserer men ikke eliminerer denne kostnaden.
Antall og kompleksitet i integrasjoner: en app som bare viser statisk innhold er billig. En app som må snakke med betalingsløsning, regnskapssystem, CRM og et eksternt API samtidig, koster vesentlig mer fordi hver integrasjon krever egen testing og feilhåndtering.
Grad av skreddersøm versus standardfunksjonalitet: innlogging, push-varsler og enkle lister er velkjent funksjonalitet som går raskt å bygge. Unike arbeidsflyter, avanserte beregninger eller sanntidsfunksjoner krever mer utviklingstid per funksjon.
Krav til sikkerhet og regelverk: apper som håndterer helsedata, betalinger eller annen sensitiv informasjon krever ekstra arbeid med tilgangsstyring, kryptering og dokumentasjon — noe som legger til kostnad som ikke er synlig i en enkel funksjonsliste.
Én plattform eller enkel cross-platform-løsning, få skjermer, ingen eller én enkel integrasjon. Typisk en MVP for å validere en idé eller en intern app med begrenset funksjonalitet.
Flere plattformer, brukerkontoer, et par integrasjoner (for eksempel betaling og et CRM), samt noe skreddersydd funksjonalitet utover standard byggeklosser.
Flere integrasjoner mot kritiske systemer, avanserte arbeidsflyter, sanntidsfunksjonalitet, høye krav til sikkerhet eller skalerbarhet, og ofte behov for egen backend-arkitektur.
Fastpris krever at scope er godt definert på forhånd. Du får trygghet på totalkostnad, men endringer underveis må håndteres som tillegg utenfor avtalt scope.
Timepris passer godt når scope forventes å endre seg, for eksempel i tidlig produktutvikling. Du betaler for faktisk medgått tid, men totalkostnaden er mindre forutsigbar.
Mange prosjekter starter med fastpris for en avgrenset MVP, og går over til timepris eller løpende avtale for videreutvikling når retningen er mer uklar.
Det viktigste for å unngå budsjettsprekk er ikke prismodellen i seg selv, men at begge parter er enige om hva som faktisk inngår før arbeidet starter.
Den vanligste feilen vi ser er at budsjettet stopper ved lansering. En app er sjelden «ferdig» når den publiseres i App Store eller Google Play — den trenger drift, overvåking, sikkerhetsoppdateringer og jevnlige oppdateringer for å følge nye versjoner av iOS og Android. Sett av et løpende driftsbudsjett, ofte i størrelsesorden 10–20 % av utviklingskostnaden per år, avhengig av kompleksitet og hvor mye videreutvikling dere planlegger.
Servere, tredjepartstjenester og API-kostnader er en annen post som lett glemmes i et første budsjett. Betalingsløsninger tar gebyr per transaksjon, kartjenester og SMS-varsling koster per bruk, og skyhosting skalerer med trafikk. Disse kostnadene er vanligvis små i starten, men bør estimeres tidlig slik at de ikke kommer som en overraskelse når appen faktisk får brukere.
App Store- og Google Play-avgifter, samt tid brukt på godkjenningsprosesser og eventuelle avslag som må rettes opp, er også en reell kostnad — både i kroner og i forsinket lansering. Vi bygger dette inn i tidsplanen fra start, men det er verdt å vite om på forhånd slik at «ferdig utviklet» ikke forveksles med «klar for brukere».
Den mest effektive måten å redusere kostnad på er ikke å forhandle timeprisen ned, men å redusere scope for første versjon. En MVP som løser ett kjerneproblem svært godt, er billigere å bygge og gir raskere læring enn en bred app med ti funksjoner der bare tre faktisk brukes av kundene. Vi anbefaler nesten alltid å kutte funksjonslisten ned til det som er nødvendig for å teste den sentrale hypotesen, og bygge resten basert på faktisk bruk etter lansering.
Cross-platform-teknologi kan redusere kostnaden betydelig sammenlignet med å bygge separat for iOS og Android, spesielt for apper uten tunge krav til plattformspesifikk ytelse eller hardware-integrasjon. Det er ikke riktig valg for alle prosjekter, men for mange MVP-er og middels komplekse apper gir det en vesentlig lavere kostnad uten å gå på akkord med brukeropplevelsen.
No-code eller low-code-plattformer kan være et reelt alternativ for enklere interne verktøy eller tidlige valideringer, og kan redusere kostnaden dramatisk sammenlignet med skreddersydd utvikling. Ulempen kommer når appen vokser forbi det plattformen er designet for — da kan en migrering til skreddersydd kode bli dyrere enn om man hadde startet der. Vi hjelper deg vurdere om no-code er riktig startpunkt for akkurat ditt behov, eller om det bare utsetter en uunngåelig kostnad.
Uansett hvilken vei du velger, er den billigste feilen å unngå en uklar kravspesifikasjon. Prosjekter som starter uten tydelig avklart scope bruker ofte 20–40 % mer tid enn planlagt, fordi endringer og misforståelser oppdages underveis i stedet for før utviklingen starter. En grundig kartleggingsfase koster lite sammenlignet med hva den sparer i endringer og re-arbeid senere i prosjektet.
Ja, for en avgrenset MVP med få skjermer og minimal integrasjon er dette et realistisk startpunkt, forutsatt at scope er tydelig avklart på forhånd.
Forskjellen ligger ofte i integrasjoner, sikkerhetskrav og unik forretningslogikk som ikke er synlig i selve brukergrensesnittet.
Ja. Vi gir en uforpliktende vurdering basert på en kort kartleggingssamtale om hva appen faktisk skal løse.
Send oss en kort beskrivelse av hva appen skal løse, hvem som skal bruke den og hvilke systemer den eventuelt må snakke med. Vi gir deg en realistisk pris- og tidsvurdering basert på faktisk scope — ikke et generisk intervall.
Vi svarer raskt med ærlig vurdering av scope, teknisk retning og realistisk fremdrift.
Gå til kontaktApputvikling-siden gir en kort oversikt med et generelt intervall på 150 000–1 500 000+ NOK. Denne siden går i dybden på hva som faktisk driver prisen innenfor det intervallet, med konkrete tall per kompleksitetsnivå, fastpris vs. timepris og skjulte kostnader.
Fastpris gir forutsigbarhet når scope er godt avklart. Timepris passer bedre når prosjektet forventes å endre retning underveis, for eksempel tidlig i produktutvikling.
Et vanlig utgangspunkt er 10–20 % av utviklingskostnaden per år, men dette varierer med kompleksitet, trafikkmengde og hvor mye videreutvikling dere planlegger.
Del kort hva du ønsker å få løst, så gir vi en konkret anbefaling av neste steg.