Å lage en app er ikke først og fremst et kodeprosjekt. Det er et prosjekt der du bestemmer hva som skal bygges, for hvem, og hva som kan vente. Gjør du det riktig, blir koden den enkle delen. Her er stegene vi følger – fra første idé til appen ligger i App Store og Google Play.
Guiden passer både for deg som skal bestille en app fra et byrå, og for deg som vurderer å bygge selv. Tidsbruken under gjelder en typisk MVP – den første versjonen av appen – og er den samme vi bruker i approsjektene våre.
1. Start med problemet – ikke med appen
Skriv ned tre ting før du tenker på skjermbilder: hvem som skal bruke appen, hvilket problem den løser for dem, og hvordan de løser det i dag. Klarer du ikke å svare kort og konkret, er ikke ideen klar for utvikling ennå.
Spør deg også om det må være en app. Skal brukerne åpne den ofte, få push-varsler, bruke kamera eller jobbe uten dekning, er en app ofte riktig. Skal de bruke den et par ganger i året, eller mest fra en PC, kan en webapp være bedre og billigere. Vi har skrevet en egen guide om webapp eller mobilapp.
2. Velg de 3–5 funksjonene som må være med
Den vanligste grunnen til at approsjekter blir dyre og sene, er at første versjon skal gjøre alt. Lag en liste over alle funksjonene du ønsker deg, og del den i tre:
- Må ha: Uten dette løser ikke appen problemet. Her bør det stå 3–5 ting.
- Bør ha: Gjør appen bedre, men brukerne kan klare seg uten i starten.
- Kan vente: Alt annet. Dette er versjon 2 – og ofte viser det seg at brukerne ønsker noe helt annet.
Det du sitter igjen med i «må ha», er MVP-en din: den minste versjonen som løser kjerneproblemet godt nok til at ekte brukere tar den i bruk. Hos oss tar dette forprosjektet typisk 3–5 dager.
3. Sjekk marked, data og regler
Søk i App Store og Google Play etter apper som løser det samme. Les de dårlige anmeldelsene – de forteller deg hva brukerne savner. Avklar samtidig tre ting som påvirker både pris og tidsplan:
- Personopplysninger: Hvilke data samler appen inn, og trenger du dem? Mindre data betyr mindre risiko og enklere personvernerklæring.
- Helseopplysninger: Er det helsedata, gjelder strengere regler – og appen kan bli medisinsk utstyr avhengig av formålet. Se guiden om helseapper.
- Betaling: Selger du digitalt innhold i appen, må du hos Apple normalt bruke kjøp i appen og betale provisjon, mens Google i EØS også åpner for alternativ betaling. Selger du fysiske varer eller tjenester som brukes utenfor appen, bruker du vanlig betaling som Vipps eller kort.
4. Lag en prototype og test den på ekte brukere
Før noen skriver kode, tegner vi skjermbildene i Figma og kobler dem sammen til en klikkbar prototype. Den ser ut og oppfører seg som en app, men koster en brøkdel å endre.
Vis prototypen til noen i målgruppen og be dem løse en oppgave uten hjelp. Du trenger ikke mange: Nielsen Norman Group har lenge anbefalt å teste med rundt fem brukere per runde, fordi de fleste brukervennlighetsproblemer dukker opp allerede da. Designfasen tar typisk rundt én uke for en MVP.
5. Velg teknologi
Nå – og ikke før – er det tid for teknologivalg. For de fleste bedriftsapper anbefaler vi Flutter, som gir én kodebase for både iPhone og Android. React Native passer hvis teamet ditt allerede kan React, og native Swift og Kotlin når appen trenger tung grafikk, AR eller dyp tilgang til maskinvaren. Les hele sammenligningen av Flutter, React Native og native.
Avklar også backend: skal appen ha innlogging, lagre data eller synkronisere mellom enheter, trenger den en server. For enklere apper kan tjenester som Firebase eller Supabase spare mye. Noen apper trenger ingen server i det hele tatt – helseappen Blood Sugar Log, som vi har utviklet, lagrer alt lokalt på telefonen.
6. Utvikle i korte runder – med testversjoner underveis
Del utviklingen i korte runder der hver runde gir en versjon du kan installere på din egen telefon, via TestFlight for iPhone og Google Play sin testing for Android. Da ser du appen vokse, og misforståelser blir oppdaget etter en uke i stedet for etter tre måneder. For en MVP tar utviklingen typisk 2–4 uker.
7. Test på ekte enheter og i ekte situasjoner
En app som fungerer på utviklerens telefon, fungerer ikke nødvendigvis på din. Test på flere enheter, skjermstørrelser og versjoner av iOS og Android. Test det som skjer når nettet forsvinner, når brukeren får en telefonsamtale midt i et skjema, og når skriftstørrelsen er satt opp. Og test med noen som ikke har sett appen før.
8. Lanser – og planlegg versjon 2
Publiseringen i App Store og Google Play har egne krav til utviklerkonto, personvern, aldersgrense og testing – og for nye personlige Google-kontoer en lukket test på 14 dager. Vi har samlet alt i guiden slik publiserer du en app.
Etter lansering begynner den viktigste læringen. Mål hva brukerne faktisk gjør, les tilbakemeldingene, og la versjon 2 bygge på data i stedet for antakelser. Sett av 15–25 prosent av byggebudsjettet per år til vedlikehold, fordi Apple og Google endrer kravene hvert år.
Hvor lang tid tar det, og hva koster det?
En typisk MVP tar 3–6 uker fra forprosjekt til lansering. En mellomklasse-app med skreddersydd design, betaling og egen backend tar 4–12 uker, og en kompleks plattform 1–3 måneder. Hva det koster, avhenger av funksjonene, designet og integrasjonene – vi har samlet priser og hva som driver dem i prisoversikten for apputvikling.
Lage selv, frilanser eller byrå?
- Selv med no-code: Verktøy som FlutterFlow, Adalo og Glide fungerer godt for prototyper og enkle interne verktøy. For en app som skal konkurrere om brukere i butikkene, treffer du raskt taket.
- Frilanser: Kan være rimelig og fleksibelt. Risikoen er kapasitet og hva som skjer med appen hvis personen blir utilgjengelig.
- Byrå: Design, utvikling og publisering fra samme sted, og noen som tar ansvar for vedlikeholdet. Det koster mer per time, men ofte mindre totalt fordi færre ting må gjøres om.
- Egne utviklere: Riktig når appen er selve kjernen i virksomheten og skal videreutvikles hele tiden.
Uansett hvem du velger, still disse spørsmålene før du signerer:
- Kan jeg se apper dere har publisert i App Store eller Google Play?
- Hvem eier kildekoden – og når overføres eierskapet?
- Ligger appen på vår utviklerkonto eller deres?
- Er prisen fast, eller betaler vi per time? Hva er inkludert?
- Hva koster vedlikehold per år, og hva skjer når Apple eller Google endrer kravene?
Fem feil som gjør apper dyre
- For mye i første versjon. Hver ekstra funksjon koster tid, penger og vedlikehold – før du vet om noen vil bruke den.
- Ingen testing med brukere før koding. Endringer i en prototype tar timer. Endringer i ferdig kode tar uker.
- Uklare beslutninger. Den største forsinkelsen i approsjekter er sjelden kodingen, men ventetid på svar.
- Glemt personvern. Personvernerklæring, Data safety og kontosletting kommer uansett – det er billigere å planlegge det fra start.
- Ikke noe budsjett etter lansering. En app som ikke oppdateres, faller ut av butikkene over tid.
Vanlige spørsmål om å lage en app
Kan jeg lage en app selv uten å kunne kode?
Ja, til en viss grad. Med no-code-verktøy kan du lage en klikkbar prototype eller et enkelt internt verktøy uten å skrive kode. Begrensningene kommer når appen skal ha egen design, tåle mange brukere eller kobles mot andre systemer. Test gjerne ideen med no-code først, og bygg appen ordentlig når du vet at noen vil bruke den.
Hvor lang tid tar det å lage en app?
En MVP tar typisk 3–6 uker: 3–5 dager forprosjekt, rundt én uke design og 2–4 uker utvikling. En mellomklasse-app tar 4–12 uker, og komplekse plattformer 1–3 måneder. Uklare krav og trege beslutninger forsinker mer enn selve kodingen.
Hvem kan lage en app for meg?
Du kan bruke en frilanser, et byrå eller ansette egne utviklere. Uansett hvem du velger: be om å se apper de har publisert, avklar hvem som eier kildekoden og utviklerkontoen, og få skriftlig hva som er inkludert i prisen og hva vedlikehold koster etter lansering.
Hva er en MVP?
MVP står for minimum viable product – den minste versjonen av appen som løser kjerneproblemet godt nok til at ekte brukere tar den i bruk. Målet er å lære hva brukerne faktisk trenger før du investerer i alle funksjonene.
Kilder
- Nielsen Norman Group: Why You Only Need to Test with 5 Users
- Apple: App Review Guidelines (betaling for varer og tjenester utenfor appen)
- Google Play: Testkrav for nye personlige kontoer