Det er vanligvis det andre spørsmålet. Rett etter budsjettet.Du har en idé. Du har begynt å tenke på funksjoner. Og på et tidspunkt trenger du å vite: hvor lang tid tar det egentlig å bygge en mobilapp?
Internett vil fortelle deg alt fra seks uker til to år. Begge er teknisk korrekte. Ingen av dem er særlig nyttige.
Og i 2026 har spørsmålet blitt mer komplisert. Mange gründere ankommer med noe allerede bygget – en prototype satt sammen med AI-verktøy over en helg. Noen ganger er den solid. Noen ganger ser den klar ut, men har hull som bare dukker opp når ekte brukere treffer den.
Uansett har utgangspunktet endret seg. Og det endrer tidslinjen også.
Hvorfor hvert svar du har funnet på nett er forskjellig
To apper kan høres nesten identiske ut og kreve helt forskjellige mengder arbeid.
En enkel app med noen få skjermer og ingen backend er et annet prosjekt enn en med brukerkontoer, betalinger, tredjeparts integrasjoner og innhold som må administreres. Begge kan beskrives som "en mobilapp for virksomheten min."
Tidslinjen for den ene kan være 8 uker. Den andre kan ta seks måneder.
Variablene som betyr mest er omfang, kompleksitet, plattformvalg og mer enn noe annet, hvor tydelig prosjektet er definert før utviklingen starter. Den siste er der de fleste tidslinjeestimater faller fra hverandre.
Tre prosjekter. Tre helt forskjellige tidslinjer.
Den beste måten å svare på spørsmålet er med ekte eksempler.
Beredt - 8 uker
Beredt er en app for beredskap for norske familier. En personlig assistent som hjelper deg å organisere forsyninger, lage sikkerhetsplaner og være forberedt på uventede situasjoner.
Kunden kom til oss i slutten av oktober. Et annet utviklingsteam hadde startet prosjektet, men stoppet opp. Målet var tydelig: lansere før jul.
Vi gjennomgikk den eksisterende koden, fant hva som manglet, fullførte kjernefunksjonene, redesignet grensesnittet og lanserte på både iOS og Android.
Åtte uker. Seks personer. Seksti skjermer.
Det er raskt. Det var mulig fordi omfanget var definert og beslutningene allerede var tatt. Teamet kunne bygge uten å stoppe for å finne ut av ting.
De åtte ukene dekket lanseringen til MVP. Det som fulgte var ytterligere seks måneder med forbedringer, nye funksjoner og justeringer basert på tilbakemeldinger fra ekte brukere. Den innledende tidslinjen får deg live. Produktet fortsetter å bevege seg etter det.
Les mer om Beredt-appen her.
Lengi - 6 måneder
Lengi er en språklæringsapp som bruker AI til å simulere ekte samtaler med morsmålsbrukere. Du øver på å snakke, får tilbakemeldinger i sanntid på meldingene dine og følger fremgangen din gjennom statistikk.
Vi håndterte alt fra begynnelsen: markedsundersøkelser, skisser, prototyping, brukertesting, AI-integrasjon, backendarkitektur og lansering på begge plattformer.
Seks måneder. Et lite team. Etter lansering: 3 000 nedlastinger, 12 betalende abonnenter i de første ukene.
Tidslinjen gjenspeiler omfanget. Sanntids AI-tilbakemeldinger, flere brukerflyter, en abonnementsmodell, nøyaktighetssjekk på tvers av språk. Disse tingene tar tid å bygge godt. Å haste dem ville ha vist seg.
Les mer om Lengi-appen her.
Pelican - 24 uker
Pelican er en app for finansiell opplæring som hjelper brukere å forstå penger, sparing og investeringer, med AI-assistert veiledning innebygd.
Vi bygde den som en nettapp først, deretter gikk vi over til mobil. MVP-en dekket et personlig finansdashbord, et kunnskapssenter med artikler og podkaster, og grunnlaget for en abonnementsmodell.
Seks personer. Tretti skjermer. Tjuefire uker for den første fasen. Produktet vokser fortsatt, med nye funksjoner lagt til basert på ekte brukerdata.
Les mer om Pelican-appen her.
Hva tallene viser
Tre prosjekter. 8 uker, 6 måneder, 24 uker.
Beredt var raskt fordi omfanget var fokusert og fristen var fast. Det var ikke rom for "hva om vi også la til..." midt i byggingen. Begrensningene hjalp.
Lengi tok lengre tid fordi det ble bygget fra bunnen av med komplekse AI-funksjoner som måtte fungere godt fra dag én. Tidslinjen ble fortjent av kompleksiteten.
Pelican er i midten. Et produkt med reell dybde, bygget i faser, med start på nett for å redusere tidlig risiko.
Forskjellige produkter, forskjellige tidslinjer. Alle rimelige for hva de var.
Det de har til felles: ingen av dem ble overrasket over hvor lang tid det tok. Fordi omfanget var tydelig før den første sprinten startet.
Hvor tid faktisk går
Det er sjelden selve utviklingen.
Omfang som fortsetter å vokse. En ny funksjon legges til midt i en sprint. En prioritet skifter. Noen ombestemmer seg om en kjernefunksjon. Hver endring midt i byggingen koster mer tid enn den samme endringen ville ha kostet før utviklingen startet.
Krav som ikke ble definert på forhånd. Når teamet må stoppe og vente på en beslutning som burde ha blitt tatt i uke én, bremser arbeidet opp. Noen ganger stopper det helt.
AI-generert kode som så ferdig ut, men ikke var det. En gründer bygger en prototype med AI-verktøy, gir den til et utviklingsteam, og teamet oppdager at kjernefunksjoner – registrering, betalinger, kanttilfeller – aldri ble skikkelig ferdigstilt. Koden kjører, men er ikke produksjonsklar. Før man kan bygge videre, må noen gå tilbake. Det er uplanlagt tid som ingen hadde budsjettert for.
Integrasjoner som så enkle ut. Å koble til en betalingsleverandør, et CRM-system eller en ekstern datakilde tar nesten alltid lengre tid enn planlagt. API-er er inkonsekvent dokumentert. Kanttilfeller multipliseres.
Tilbakemeldingssykluser som drar ut. En to ukers forsinkelse på en designgjennomgang, gjentatt tre ganger, er seks uker av tidslinjen din. Dette er en av de vanligste og mest forebyggbare årsakene til forsinkelser.
Det ene steget som forutsier alt annet
Prosjekter som starter med en tydelig spesifikasjon blir ferdig raskere.
Ikke litt raskere. Konsekvent, målbart raskere – med færre overraskelser og færre kostnader som ikke var i den opprinnelige planen.
Hvis du bygger en mobilapp, betyr den klarheten enda mer – mobilprosjekter har flere variabler enn de fleste.
En tydelig spesifikasjon betyr en avtalt funksjonsliste for versjon én, dokumenterte brukerflyter, definerte tekniske begrensninger og en felles forståelse av hva suksess ser ut som ved lansering. Ikke om seks måneder. Fra dag én.
Det er det et Discovery Workshop er for.
Før noen bygging starter, går vi gjennom produktet sammen. Hva som bygges, i hvilken rekkefølge, og hva som venter til versjon to. Hvilken plattform som gir mening. Hvilke integrasjoner som trengs fra dag én versus senere. Hvor risikoene er. Du går derfra med et dokument – ikke en presentasjon, men en faktisk spesifikasjon som et utviklingsteam kan jobbe fra.
Det er steget de fleste prosjekter hopper over. Det er også det som de fleste forsinkede og overskuddede prosjekter skulle ønske de ikke hadde.
Vil du vite hvor lang tid appen din faktisk vil ta? Start her.
