En mobilapp er som regel den største post i en virksomheds digitale budget – og den største ubekendte. Du har sikkert set tilbud på „app fra 1.150 € ekskl. moms" ved siden af tilbud på en halv million. Begge dele kan være rigtige, for „app" betyder alt og ingenting. Lad os se på, hvad en app koster, punkt for punkt.
Eurobeløb er omregnet til NBP's midtkurs den 14.09.2026 (1 € = 4,3391 zł) og afrundet. Vi fakturerer i PLN.
Hvad køber du egentlig?
En mobilapp består af mindst tre dele: appen på telefonen (det, brugeren ser), backend (server, database, logik – usynligt, men det udgør typisk halvdelen af omkostningerne) og et administrationspanel, hvor du styrer indhold og brugere. Dertil kommer udgivelse i App Store og Google Play med deres krav.
Cross-platform eller native?
I 2026 er svaret for de fleste virksomheder: cross-platform (React Native eller Flutter). Én kodebase kører på både iOS og Android, hvilket sænker prisen for app udvikling og vedligeholdelse med 30–40 % i forhold til to separate native apps. Native Swift/Kotlin vælges i dag primært til spil, apps der bruger hardwaren intensivt (kamera, sensorer, AR) og produkter med ekstreme krav til ydeevne.
Hvad koster en app: prisintervaller
Med markedets timepriser (hos os: udvikling 46 €/t, design 35 €/t ekskl. moms) ser udvikling af app-pris sådan ud:
140–360 timer: nøglefunktionen, en enkel backend, udgivelse i app-butikkerne. Formålet: at teste idéen på rigtige brugere.
Brugerkonti, betalinger, push-beskeder, administrationspanel, analyse.
Mange moduler, integrationer med eksterne systemer, avanceret logik, høj skala.
Hvad skal du huske, når du lægger budget?
- Vedligeholdelse udgør 15–25 % af byggeomkostningen om året – systemopdateringer, rettelser, mindre videreudvikling. En app uden pasning „går i stykker" efter hver større opdatering af iOS/Android.
- Udviklerkonti: Apple 99 USD/år, Google 25 USD som engangsbeløb.
- Server: fra ca. ti euro til et par hundrede euro om måneden afhængigt af antallet af brugere.
Hvordan sænker du prisen på den første version?
Start med et MVP. Vælg den ene funktion, som brugeren reelt kommer for, og byg den ordentligt. Lad „nice to have"-listen vente til version 2.0 – den finansieres af et produkt, der virker. Det er ikke et kompromis med kvaliteten, men en strategi, som stort set alle kendte apps er startet med.