Udvikling af mobilapp til virksomhed, pris og proces (komplet guide 2026)

Indholdsfortegnelse

• Hvad koster en B2B-mobilapp i Danmark
• De fire pristrin og hvad de typisk indeholder
• Native vs cross-platform, hvad skal du vælge
• Hvor lang tid tager det at bygge en mobilapp
• Otte spørgsmål du skal svare på inden du beder om tilbud
• Hvorfor MVP-tilgang slår alt-på-én-gang
• Driftsomkostninger efter lancering
• Når mobilappen er en del af en større platform
• FAQ, ofte stillede spørgsmål om udvikling af mobilapp til virksomhed
• Læs også

Når en dansk virksomhed beslutter sig for at få bygget en mobilapp, er det første spørgsmål næsten altid det samme: “Hvad koster det?” Det er et fair spørgsmål, men det er også det forkerte sted at starte. Udvikling af mobilapp til virksomhed kan koste alt fra 200.000 kr for et fokuseret MVP til over 2 millioner for en kompleks platform med native iOS- og Android-apps, backend, integration og driftsmiljø. Forskellen handler ikke om udviklerens timepris, men om hvor godt I har defineret hvad I vil bygge.

Denne guide gennemgår realistiske prisintervaller for B2B-mobilapps i Danmark, forskellen mellem native og cross-platform tilgange, hvor lang tid det realistisk tager, og hvilke otte spørgsmål I skal kunne besvare inden I beder om et meningsfuldt tilbud. Vi argumenterer også for, hvorfor en MVP-tilgang næsten altid slår “alt på én gang”, og vi forklarer hvor en mobilapp passer ind, hvis den skal være en del af en større skræddersyet SaaS-platform.

Overvejer I at konsolidere stacken eller bygge skræddersyet? Decree har bygget hele platformen selv. Hvis I har en niche-proces, bygger vi den ind. Se vores løsninger eller book en samtale.

Hvad koster en B2B-mobilapp i Danmark

Lad os starte med det ærlige svar. Prisintervallet er bredt, fordi scope er den dominerende variabel. Her er de typiske niveauer for udvikling af mobilapp til virksomhed i Danmark, baseret på markedet i 2025-2026.

Tallene er for selve udviklingsprojektet. De inkluderer ikke driftsomkostninger, vedligeholdelse, butiksgodkendelse, eller løbende videreudvikling. Vi vender tilbage til disse poster senere.

Hvad bestemmer prisen

De fire faktorer der styrer prisen for udvikling af mobilapp til virksomhed, er:

1. Antallet af skærme og funktioner. Hver skærm kræver design, kode, test og dokumentation. Tommelfingerregel: 30.000 til 80.000 kr per skærm afhængig af kompleksitet.
2. Antallet af platforme. Cross-platform (én kodebase til iOS og Android) er typisk 30 til 50 procent billigere end at bygge separate native apps.
3. Backend-kompleksiteten. Hvis appen kræver en dedikeret backend, ny database, custom API, kan det fordoble totalprisen. Hvis den bygger ovenpå en eksisterende platform, kan det halvere prisen.
4. Integrationer. Hver integration med eksterne systemer (ERP, CRM, lønsystem, branchespecifikke værktøjer) tilføjer typisk 50.000 til 200.000 kr afhængigt af kompleksitet.

Læs mere om hvordan vi bygger mobilapps som del af en samlet platform.

De fire pristrin og hvad de typisk indeholder

For at gøre prisintervallerne mere konkrete, så kan vi nedbryde hvert pristrin i typisk indhold.

MVP-niveau: 200.000 - 500.000 kr

Dette er en fokuseret app der løser et specifikt problem. Den findes i én version (typisk cross-platform via React Native eller Flutter), har en håndfuld kerne-skærme, og er bevidst begrænset i funktionalitet. Det er den rigtige startposition for de fleste virksomheder.

Eksempel-scope:

• Login (email + password, eller SSO mod jeres identity-provider)
• Dashboard med 3-5 KPI’er
• Liste-/detalje-flow for én datatype (f.eks. ordrer, opgaver, kunder)
• Push-notifikation ved relevant hændelse
• Basal offline-cache så appen virker uden netforbindelse

Tidsramme: 3 til 5 måneder

Standard B2B-app: 500.000 - 1.200.000 kr

Dette er den typiske størrelse for en seriøs B2B-app, der skal bruges af 50 til 500 medarbejdere dagligt. Begge platforme (iOS og Android), bredere funktionalitet, og typisk integration med 1-2 eksisterende backend-systemer.

Eksempel-scope:

• Multi-rolle login med rollebaseret adgang
• 8-15 skærme der dækker hovedforretningsprocessen
• Integration med eksisterende ERP eller CRM
• Push-notifikationer baseret på events
• Offline-funktionalitet med konfliktløsning
• Adgang til data via filtrering og søgning
• Basal in-app-kommunikation eller chat

Tidsramme: 6 til 9 måneder

Avanceret B2B: 1.200.000 - 2.500.000 kr

På dette niveau er appen typisk virksomhedskritisk, bruges af mange brugere, og har komplekse krav til offline-arbejde, sikkerhed og auditerbarhed.

Eksempel-scope:

• Komplet rolle- og rettighedsstyring
• 20+ skærme med komplekse arbejdsflows
• Avanceret offline-funktionalitet med multi-device sync
• Integration med 3-5 backend-systemer
• Audit-log af alle handlinger
• Krypteret lokal datalagring
• Custom UI-komponenter for komplekse skærme
• Detaljeret analytics og brugersporing
• App-internt support- og hjælpsystem

Tidsramme: 10 til 15 måneder

Native dual-platform: 2.000.000 - 5.000.000 kr

Dette niveau ses typisk ved consumer-apps eller B2B-apps med ekstreme krav til performance, native funktionalitet (kamera, AR, biometri, hardware-integration) eller pixel-perfect UX. For de fleste B2B-formål er det overkill.

Eksempel-scope:

• Separate iOS- (Swift) og Android- (Kotlin) apps med native UX
• Avanceret hardware-integration (kamera, NFC, BLE, GPS)
• Optimeret for offline-first brug
• Custom design-system implementeret i native komponenter
• Real-time data via WebSockets
• Egen backend optimeret til appens specifikke behov

Tidsramme: 15 til 24 måneder

Native vs cross-platform, hvad skal du vælge

Den tekniske beslutning der har størst indflydelse på pris og tidslinje, er valget mellem native og cross-platform. Her er de praktiske forskelle.

Native iOS og Android

I bygger to separate apps, én i Swift (iOS) og én i Kotlin (Android). Hver app har sin egen kodebase, sit eget team, sin egen build-pipeline.

Fordele:

• Bedst mulige performance og UX
• Direkte adgang til native funktionalitet (hardware, OS-features)
• Følger platformens design-konventioner
• Bedst app-butiksoptag

Ulemper:

• Cirka 60 til 100 procent dyrere end cross-platform
• To kodebaser at vedligeholde
• Funktionsudvidelser tager dobbelt så lang tid
• Kræver udviklere med specialiserede færdigheder

React Native

Cross-platform framework udviklet af Meta. Én kodebase i JavaScript/TypeScript, deployes til både iOS og Android. Renderer native UI-komponenter under motorhjelmen, så slutbrugeroplevelsen er tæt på native.

Fordele:

• Én kodebase, betydelig udviklingsbesparelse
• Stor økosystem og mange tilgængelige biblioteker
• Bred udviklerpool i Danmark
• Mature framework med dokumenteret produktionsbrug (Facebook, Instagram, Discord, Shopify m.fl.)

Ulemper:

• Performance er god men ikke 100 procent native
• Native modules kan kræves til specifik hardware-integration
• Visse OS-opdateringer kan kræve hurtige framework-opgraderinger

Flutter

Cross-platform framework fra Google. Bruger Dart-sproget og renderer egne UI-komponenter via en grafisk motor (ikke native komponenter).

Fordele:

• Konsistent UI på tværs af platforme (alle pixels under jeres kontrol)
• Stærk performance, ofte bedre end React Native
• God for apps med custom design-system
• Voksende fællesskab og økosystem

Ulemper:

• Mindre udviklerpool end React Native i Danmark
• Egne UI-komponenter giver mindre native følelse
• App-binær er typisk større end native eller React Native

Vores anbefaling for B2B

For de fleste B2B-mobilapps er React Native det rigtige valg. Det balancerer udviklingseffektivitet, performance og udviklerpool på en måde, der passer til SMV-budgetter og tidslinjer. Native iOS og Android giver kun mening, hvis appen skal lave noget der kræver dyb hardware-integration, eller hvis I har et internt udviklingsteam med specialiserede native-færdigheder.

Flutter er et stærkt valg for apps, hvor designet er den primære differentiator og hvor I har et team, der kan investere i Dart.

Hvor lang tid tager det at bygge en mobilapp

Tidslinjen følger pristrinnet, men der er nogle generelle faser, der altid indgår.

Standardfaser i et mobilapp-projekt

I praksis kører faserne overlappende, men den samlede tid er typisk:

• MVP: 12 til 20 uger
• Standard B2B: 24 til 36 uger
• Avanceret B2B: 40 til 60 uger
• Native dual-platform: 60 til 100 uger

Den underestimerede del: butiksgodkendelse

App Store og Google Play har en review-proces, der kan tage fra dage til uger. Apple er især kendt for at afvise apps på grund af mindre tekniske detaljer. Planlæg minimum to uger til godkendelse, og forvent at I sandsynligvis skal igennem en eller to revisioner.

Hvis appen er en intern medarbejder-app, der ikke skal i offentlige butikker, kan I skippe denne fase ved at distribuere via MDM (Mobile Device Management) eller Apple Business Manager.

Otte spørgsmål du skal svare på inden du beder om tilbud

Et tilbud på udvikling af mobilapp til virksomhed er kun præcist, hvis I kan beskrive scope præcist. Her er de otte spørgsmål, vi altid stiller til en ny kunde, før vi kvalificerer et tilbud.

1. Hvem er den primære bruger, og hvornår bruger de appen?

En sælger der bruger appen 5 minutter mellem møder, har andre behov end en feltarbejder, der bruger den 6 timer dagligt. Forskellen påvirker UX, offline-strategi og performance-krav direkte.

2. Hvad er det ene problem, appen skal løse?

Hvis svaret er en liste, så er scope ikke modent endnu. Find det ene problem, der har størst værdi, og start der. Resten kan komme i version 2.

3. Skal appen virke offline?

Offline-funktionalitet kan tilføje 30 til 50 procent til udviklingsbudgettet, fordi konfliktløsning, lokal datalagring og synkronisering er komplekst. Vær ærlig om det reelle behov, ikke det opfattede.

4. Hvilke systemer skal appen integrere med?

Hver integration er en omkostning. ERP, CRM, lønsystem, identity-provider, eksterne API’er. Lav listen tidligt, og gennemgå hver integration for: er det nødvendigt fra dag ét, eller kan det vente.

5. Hvor mange brugere, og hvor høj er forventet brugsintensitet?

Hvis appen skal bruges af 50 brugere et par gange dagligt, er den teknisk arkitektur en helt anden, end hvis den skal håndtere 5.000 brugere med konstant aktivitet. Forventet skala styrer backend-arkitekturen.

6. Skal den i offentlige app-butikker eller distribueres internt?

Offentlige butikker betyder review-proces, app store-optimering, opdateringscyklusser og specifikke designkrav. Intern distribution via MDM er teknisk simplere, men kræver MDM-infrastruktur.

7. Hvad er jeres compliance- og sikkerhedskrav?

GDPR, NIS2, branchespecifik regulering. Hvis I behandler følsomme data, skal app, backend og dataopbevaring leve op til specifikke standarder. Det skal med i scoping fra start.

8. Hvem ejer produktansvaret internt?

Den vigtigste faktor for at et mobilapp-projekt lykkes, er at I har én intern person, der træffer beslutninger om scope og prioritering. Uden klar produktansvarlig drukner projektet i kravudredning.

Når I kan svare præcist på alle otte, er I klar til at modtage et meningsfuldt tilbud. Tag fat i os hvis I vil gennemgå spørgsmålene sammen.

Hvorfor MVP-tilgang slår alt-på-én-gang

Den største fejl ved udvikling af mobilapp til virksomhed er at forsøge at bygge “den endelige version” i ét hug. Det fører næsten altid til:

• Forsinket lancering fordi scope vokser undervejs
• Forkerte features fordi I gætter på hvad brugerne vil have
• Højere omkostninger fordi I bygger ting ingen bruger
• Lavere brugeradoption fordi appen er for kompleks ved lancering

MVP-tilgangen (Minimum Viable Product) løser dette ved at bygge mindst muligt der løser det vigtigste problem, og derefter iterere baseret på reel brug.

Hvad MVP konkret betyder

Et MVP er ikke en “billig version” af det endelige produkt. Det er en fokuseret version, der løser ét specifikt problem til den faktisk berørte brugergruppe. Hvis I bygger en app til feltarbejdere, så er MVP’et de tre skærme, der løser deres mest tidskrævende daglige opgave. Resten kan vente.

Karakteristika ved et godt MVP:

• Løser ét specifikt problem
• Har 3-5 kerne-skærme, ikke 15
• Er klar på 12-20 uger, ikke 12-20 måneder
• Bruges af reelle slutbrugere fra dag ét
• Indsamler data om reel brug, ikke bare antagelser
• Koster 200.000 til 500.000 kr, ikke 2 millioner

Hvad I lærer ved at lancere tidligt

Når MVP’et er i drift, opdager I systematisk at:

• Nogle features I tænkte var vigtige, bruges aldrig
• Nogle features I ikke havde tænkt på, viser sig at være kritiske
• Tekniske udfordringer dukker op, som ingen kravudredning kunne forudse
• Brugere har præferencer der ikke matchede jeres antagelser

Disse læringer er helt afgørende for at version 2 bygges på reel viden, ikke på antagelser. Erfaringen fra utallige mobilapp-projekter viser, at virksomheder der lancerer en MVP og itererer, ender med en bedre app for færre penge end virksomheder, der bygger “alt på én gang.”

Driftsomkostninger efter lancering

Selve udviklingsprojektet er kun starten. En mobilapp i drift har løbende omkostninger, som skal med i den langsigtede TCO.

Typiske årlige driftsomkostninger

For en app der oprindelig kostede 800.000 kr at bygge, er en realistisk årlig driftsomkostning typisk 250.000 til 500.000 kr. På fem år ender den samlede TCO derfor ofte 2 til 3 gange højere end den oprindelige byggepris.

Hvad kan reducere driftsomkostningen

• At appen bygger på en eksisterende platform. Hvis backend, identity og infrastruktur deles med øvrig stak, falder hostings- og vedligeholdelsesomkostningen markant.
• Vælg moden teknologi. React Native og Flutter har stabile opdateringscykler. Lav-kode-platforme har ofte hurtigere ændring og højere risiko for breaking changes.
• Begræns OS-versioner I supporterer. At supportere de seneste 2-3 iOS- og Android-versioner i stedet for de seneste 5 reducerer test- og bugfix-omkostning.

Når mobilappen er en del af en større platform

For B2B-mobilapps er det ofte den rigtige tilgang at bygge appen som en udvidelse af en større skræddersyet SaaS-platform, snarere end som et standalone produkt.

Fordelen er, at:

• Backend genbruges. Mobilappen taler til samme API som webportalen, ingen dobbelt-implementering
• Identity og rettigheder genbruges. Brugeradministration sker ét sted
• Datamodel er konsistent. Hvad der ses i mobilappen, er hvad der ses i webportalen
• Vedligeholdelsesomkostning halveres. Ét backend-team i stedet for to
• Udvikling er hurtigere. Nye features bygges én gang, ikke to

Hos Decree bygger vi mobilapps som moduler i platformen. Det betyder at en kunde der allerede har CRM, dokumenter og signering hos os, kan få en mobilapp der taler direkte til samme datamodel uden integrationsarbejde. Læs mere om mobilapps som del af platformen, eller om hvordan skræddersyet SaaS og mobilapp hænger sammen i skræddersyet saas-løsningen.

FAQ, ofte stillede spørgsmål om udvikling af mobilapp til virksomhed

Hvor meget koster en simpel medarbejder-app?

En simpel medarbejder-app med login, dashboard og 3-5 funktionsskærme koster typisk 200.000 til 500.000 kr at udvikle. Tilføj cirka 100.000 til 250.000 kr årligt i driftsomkostning. Hvis appen bygger på en eksisterende platform med færdig backend, kan startprisen falde med 30 til 50 procent.

Hvor lang tid tager det at få en B2B-app i app-butikkerne?

Selve udviklingen tager 3 til 9 måneder afhængigt af scope. Apples App Store review tager typisk 1 til 7 dage, men kan trække ud hvis der er afvisninger. Google Play er hurtigere, ofte under 24 timer for opdateringer. Plan for 1 til 3 uger ekstra til butiksgodkendelse fra første indsendelse.

Skal vi bygge native iOS og Android, eller cross-platform?

For de fleste B2B-formål er cross-platform (typisk React Native) det rigtige valg. Det er 30 til 50 procent billigere at udvikle, vedligeholdelse er enklere, og slutbrugerens oplevelse er tæt på native. Native bør kun vælges, hvis I har specifikke krav til hardware-integration, performance eller pixel-perfect design, der ikke kan opfyldes cross-platform.

Hvad er forskellen på en intern medarbejder-app og en kundevendt app?

Intern app distribueres ofte via MDM eller Apple Business Manager, undgår offentlig app-butiksreview, og kan have mere specialiserede UX-konventioner. Kundevendt app skal igennem App Store/Google Play, skal følge butiksretningslinjer, og skal være mere intuitiv for ukendte brugere. Internt har lavere distributionskompleksitet, kundevendt har højere designkrav.

Hvor lang tid varer en B2B-app før den skal omskrives?

En velbygget mobilapp har typisk 3 til 5 års levetid før en større omskrivning er nødvendig. Hovedårsagerne til omskrivning er: framework-versioner der ikke længere supporteres, UX-konventioner der har ændret sig markant, eller forretningsbehov der er vokset ud af den oprindelige arkitektur. Inden for de 3 til 5 år bør I forvente løbende mindre opdateringer, men ikke en fuld omskrivning.

Hvordan beskytter vi følsomme data i appen?

Følsomme data skal krypteres både i transit (HTTPS, certifikat-pinning) og i hvile på enheden (iOS Keychain, Android Keystore). Lokal cache skal have udløb. Authentication bør bruge biometri (Face ID, Touch ID) eller stærke PIN-koder. For NIS2-omfattede virksomheder kommer der yderligere krav om logning, audit og incident-respons, der skal indarbejdes i app-arkitekturen fra start.

Kan vi få en MVP for under 200.000 kr?

Det er sjældent realistisk hvis I går til et professionelt udviklingsbureau. Under 200.000 kr får I typisk en simpel forklædt webside i en native shell, ikke en reel mobilapp. Hvis budgettet er under 200.000 kr, er den bedre tilgang at bygge en mobilvenlig web-applikation først, validere brugen, og bagefter beslutte om en native eller cross-platform app er nødvendig.

Læs også

• Skræddersyet SaaS-platform vs standard software, build vs buy-guide
• Samlet it-platform eller best-of-breed for SMV
• Mobilapps som del af Decree-platformen
• Skræddersyet SaaS-udvikling, sådan arbejder vi
• Decree-platformen, hele stakken samlet

Vil du samle din virksomheds digitale rygrad hos én dansk leverandør? Decree bygger og driver hele stakken (mail, signering, telefoni, CRM, dokumenter, eLearning) plus skræddersyede SaaS-platforme og mobilapps. Alt hostet i EU, CLOUD Act-fri, samlet i én DPA. Se platformen eller kontakt os for en samtale.