“Hvad koster det at få lavet en app?” er et af de spørgsmål der sjældent har et simpelt svar — men som fortjener et ærligt et.
Sandheden er at prisen afhænger af hvad appen skal kunne, hvem der skal bruge den, og hvilken kvalitet I kræver. Men der er mønstre der gør det muligt at navigere.
Denne guide giver dig et realistisk billede af prisniveauer for app-udvikling i Danmark i 2026 — og hvad du faktisk får for pengene.
Hvad bestemmer prisen på en app?
Prisen på en app er summen af de timer det tager at designe, bygge og teste den — ganget med timepris.
De faktorer der driver prisen op:
Kompleksitet af funktioner En app der kun viser statisk information koster en brøkdel af en app der synkroniserer data i realtid, håndterer betalinger og har brugerlogin.
Antal platforme En webapp (kører i browser) koster typisk 30–50% mindre end en native iOS + Android app. En webapp kan dog bruges på alle enheder.
Integrationer Skal appen tale med e-conomic, HubSpot, et betalingssystem eller et internt system? Hver integration tilføjer tid.
Brugerlogin og roller Én type bruger er simpelt. Kunder + administratorer + medarbejdere med forskellige rettigheder er komplekst.
Design Et genbrugt komponent-bibliotek er billigt. Et skræddersyet visuelt design med animationer er dyrt.
Prisniveauer — hvad får du for hvad?
| Budget | Hvad du realistisk kan bygge |
|---|---|
| DKK 20.000–80.000 | Enkel webapp med statisk indhold, én brugertype, ingen integration |
| DKK 50.000–150.000 | Selvbetjeningsportal med login, datahentning og 1–2 integrationer |
| DKK 150.000–500.000 | Fuldt funktionel forretningsapp med flere brugerroller, integrationer og custom design |
| DKK 500.000+ | Kompleks platform, native app til iOS + Android, eller høj-volumen system |
App vs. webapp: hvad er forskellen og hvad bør du vælge?
Webapp: Kører i browseren. Fungerer på alle enheder. Kan laves som PWA (Progressive Web App) der kan installeres på telefon. Billigere at bygge og vedligeholde.
Native app: Bygget specifikt til iOS eller Android. Bedre adgang til telefonfunktioner (kamera, GPS, push-notifikationer). Kræver to separate kodebaser (eller React Native/Flutter der reducerer det).
Vores anbefaling: Begynd med en webapp. Gå kun til native app hvis I har konkrete behov der kræver det — f.eks. offline-brug, intensivt kamera-brug eller avancerede push-notifikationer.
De fleste forretningsmæssige use cases løses fint med en webapp.
Den skjulte pris: vedligehold og drift
Mange undervurderer de løbende omkostninger:
- Hosting: DKK 500–5.000/måned afhængigt af belastning
- Opdateringer: iOS og Android opdateres løbende og kræver tilpasninger
- Nye funktioner: Forretningsbehov ændrer sig — sæt af budget til iteration
- Support: Hvad sker der når noget går galt kl. 8 om morgenen?
Som tommelfingeregel: budgetter 10–20% af udviklingsomkostningen per år til vedligehold.
Hvornår giver det mening at bruge en ekstern leverandør?
Altid, medmindre I har en intern udvikler med tid og kompetencer til netop jeres teknologistack.
Vælg en leverandør der:
- Kender jeres branche eller lignende use cases
- Leverer en kravspecifikation inden de begynder at kode
- Kan dokumentere og overdrage kildekode
- Har referencer fra lignende projekter
Sådan kommer du i gang
1. Skriv en grov feature-liste — hvad skal appen kunne? Hvem skal bruge den? 2. Prioriter must-have vs. nice-to-have — hvad er MVP’en? 3. Indhent 2–3 tilbud — sammenlign ikke kun pris, men også hvad der er inkluderet 4. Insistér på en kravspecifikationsfase — undgå leverandører der springer direkte til kodning
Hos Sanocast starter vi altid med en kravspecifikation og arkitekturfase. Det giver jer en fast plan og et overblik over scope, økonomi og tidsramme — ikke en åben regning. Kontakt os.
Ofte stillede spørgsmål
Kan vi bruge en lavpris-platform som Bubble eller Webflow til at spare penge? Ja, til simple use cases. No-code platforme er gode til prototyper og interne tools med lavt volumen. De skalerer dog dårligt og giver lav fleksibilitet ved specifikke forretningsbehov.
Hvad er en MVP og bør vi starte der? MVP (Minimum Viable Product) er den mindste version af appen der løser kerneopgaven. Vi anbefaler altid at starte med en MVP og iterere baseret på reel brug. Det reducerer risikoen markant.
Kan I give et fast tilbud — ikke et timepris-estimat? Ja i mange tilfælde. Efter en kravspecifikation leverer vi et fast tilbud med scope, pris og tidsplan.
Hvad sker der hvis kravene ændrer sig undervejs? Det gør de altid. Vi arbejder med change requests: ændringer dokumenteres og prissættes inden de implementeres, så I aldrig får en overraskelse på fakturaen.