Gå til indhold

Hvad koster en webapp? 3 prisniveauer med eksempler (2026)

Hvad koster en webapp i 2026? Se tre prisniveauer fra internt værktøj til platform, typisk timeforbrug og de faktorer der flytter prisen mest.

Af

Freelance full-stack udvikler

Udgivet
Læsetid
9 min.
Indhold i indlægget8

Hvad koster en webapp? Mit grove skøn for 2026 er 80.000-300.000 kr. for et internt værktøj, 200.000-700.000 kr. for en kundevendt webapp med login og betaling og fra ca. 500.000 kr. for en platform med flere typer brugere (alle priser ekskl. moms). Det der flytter prisen mest, er sjældent antallet af skærmbilleder, men integrationer, rettigheder og hvor meget der skal virke fra første dag.

Tallene bygger på typisk timeforbrug og de timepriser der er normale for erfarne freelanceudviklere i Danmark. Jeg er selv freelancer, så brug dem som udgangspunkt for en snak og ikke som et tilbud.

Den korte version

Hvad koster en webapp? Tre prisniveauer (groft skøn, ekskl. moms)
Internt værktøjKundevendt webappPlatform
Typiske eksemplerAfløser for et regneark, vagtplan, adminpanelKundeportal, selvbetjening, booking med betalingMarkedsplads, SaaS med abonnementer, system med flere brugertyper
Hvem bruger denDine egne medarbejdereDine kunderFlere grupper med hver deres behov
Typisk timeforbrug100-250 timer250-600 timer600-2.000+ timer
Groft prisskøn80.000-300.000 kr.200.000-700.000 kr.Fra ca. 500.000 kr.
Typisk tid til første version1-3 måneder2-6 måneder6-12 måneder eller mere

Skønnet er regnet med en timepris på 800-1.200 kr. Det er et udgangspunkt og ikke en prisliste: to webapps i samme kolonne kan sagtens ligge i hver sin ende af intervallet.

Min tommelfingerregel er enkel. Skal kun dine egne folk bruge den, er du på det første niveau. Skal dine kunder logge ind, er du på det andet. Skal flere typer brugere handle med hinanden eller betale abonnement, er du på det tredje.

Vil du se hvordan webapps passer ind i det samlede billede sammen med hjemmesider, apps og vedligehold, har jeg samlet det i en prisguide til softwareudvikling.

Sådan bliver prisen regnet ud

Næsten alle tilbud på en webapp bygger på det samme regnestykke: antal timer gange timepris. Selv en fast pris er et timeskøn med et tillæg for risiko.

Timeprisen afhænger af hvem du vælger. Ifølge LønRadars oversigt over timepriser for IT-freelancere i 2026 ligger erfarne freelancere i Danmark typisk på 800-1.200 kr. i timen ekskl. moms, mens mellemniveauet ligger på 600-900 kr. Bureauer ligger som regel højere, fordi timeprisen også skal dække projektledelse, salg og kontor.

Derfor er timeprisen sjældent det vigtigste tal. En udvikler til 700 kr. der bruger 400 timer, er dyrere end en til 1.000 kr. der bruger 250. Erfaring viser sig mest i de timer der ikke bliver brugt: på at bygge det forkerte, på at rette fejl og på at lave om bagefter. Jeg har skrevet mere om hvad der er en normal timepris for freelanceudviklere, og hvordan du sammenligner dem.

Timerne er den store ubekendte. De dækker ikke kun programmering, men også afklaring, skitser af skærmbilleder, test, opsætning af server, overdragelse og de rettelser der altid kommer efter lanceringen. Et realistisk tilbud har alle posterne med. Mangler de, kommer de typisk senere som ekstraregninger.

De tre prisniveauer forklaret

Internt værktøj: 80.000-300.000 kr.

Et internt værktøj bruges af dine egne medarbejdere. Typisk afløser det et regneark der er vokset fra sig, en proces der kører i mails, eller et gammelt system ingen tør røre. Det kan være et værktøj til vagtplaner, en samlet oversigt over ordrer fra flere systemer eller et adminpanel hvor kundeservice kan slå data op.

Det er det billigste niveau, fordi du kan slække mere på kravene. Brugerne kan få en kort introduktion, designet kan bygge på et færdigt komponentbibliotek, og hvis noget driller, sidder brugeren på kontoret ved siden af. I den lave ende ligger et værktøj med ét formål og en håndfuld skærmbilleder. I den høje ende ligger værktøjer med flere roller, rapporter og en integration eller to til fx dit økonomisystem.

Kundevendt webapp: 200.000-700.000 kr.

Når dine kunder skal logge ind, stiger kravene. Fremmede skal kunne bruge løsningen uden hjælp, på mobilen og i den browser de nu har. Der skal være nulstilling af adgangskode, mails der rent faktisk kommer frem, og en plan for hvad der sker når noget fejler en fredag aften.

Typiske eksempler er en kundeportal hvor kunderne ser ordrer og fakturaer, en bookingløsning med betaling online eller et selvbetjeningsværktøj der aflaster kundeservice. Persondata og betaling stiller krav til sikkerhed og dokumentation. Brugeren ser det ikke, men det tager tid at gøre ordentligt, og det er en stor del af forskellen på de to første niveauer.

Platform: fra ca. 500.000 kr.

En platform har flere typer brugere med hver deres behov og rettigheder. Det kan være en markedsplads med købere og sælgere, et SaaS-produkt hvor hver kundevirksomhed har sin egen konto, eller et system hvor kunder, medarbejdere og samarbejdspartnere arbejder i de samme data.

Her vokser kompleksiteten hurtigere end listen over funktioner. Hver ny brugertype skal have sine egne skærmbilleder, rettigheder og notifikationer, og alt skal testes på tværs. Abonnementer, prøveperioder, opgraderinger og opsigelser fylder langt mere end de ser ud til på tegnebrættet. Skal du bygge et abonnementsprodukt, så se også min gennemgang af hvad det koster at udvikle en SaaS.

Intervallet er åbent opad, fordi platforme sjældent bliver færdige. Mange starter med en første version på 600-1.000 timer og bygger videre, efterhånden som brugerne kommer.

Det der flytter prisen mest

Inden for hvert niveau er det de samme faktorer der skubber prisen op eller ned. Her er dem jeg kigger efter først, når jeg vurderer en opgave.

Faktorer der flytter prisen på en webapp
Hvorfor det kosterSådan holder du prisen nede
IntegrationerAndre systemers API'er er sjældent så veldokumenterede som man håber, og fejl skal håndteres i begge enderStart med én integration, og brug import fra fil hvor det er godt nok
Brugertyper og rettighederHver rolle ganger antallet af skærmbilleder, regler og testsStart med de to vigtigste roller
Betaling og faktureringAbonnementer, refusioner, moms og afviste betalinger skal alle håndteresBrug en færdig betalingsløsning som Stripe i stedet for at bygge selv
DesignEt unikt design tager længere tid end et gennemprøvet komponentbibliotekBrug et færdigt designsystem til interne værktøjer
Eksisterende dataGamle data er ofte rodede og skal renses, før de kan flyttesRyd op i data før projektet starter
Krav udefraGDPR, tilgængelighed og branchekrav kræver dokumentation og testAfklar kravene i et forprojekt og ikke efter lanceringen
Krav til driftssikkerhedAutomatiske tests, backup og overvågning koster timer nu, men sparer dem senereVælg niveauet bevidst ud fra hvor kritisk løsningen er

Integrationer er den faktor der oftest bliver undervurderet. På et møde lyder det som en enkelt linje: "den skal hente ordrer fra vores ERP-system" (virksomhedens centrale forretningssystem). I praksis afhænger timerne af om systemet har et ordentligt API, om der findes et testmiljø, og hvem hos leverandøren der svarer på spørgsmål. Bed derfor om at hver integration bliver prissat for sig i tilbuddet.

Krav udefra skal også afklares tidligt. Er din webapp fx en webshop eller en billetplatform rettet mod forbrugere, kan den være omfattet af EU's tilgængelighedskrav, som gælder for produkter og tjenester bragt i omsætning efter 28. juni 2025. Servicevirksomheder med færre end 10 ansatte og under 2 mio. euro i omsætning er undtaget. Det her er ikke juridisk rådgivning, så tjek med en rådgiver hvis du er i tvivl.

Udgifterne efter lanceringen

En webapp er ikke en engangsudgift. Den skal have server, domæne, afsendelse af mails, backup og overvågning. For en typisk webapp løber det op i et par hundrede til et par tusinde kroner om måneden, afhængigt af trafik og krav.

Derudover kommer vedligehold: sikkerhedsopdateringer, nye versioner af framework og afhængigheder og de små rettelser der dukker op, når rigtige brugere tager løsningen i brug. En almindelig tommelfingerregel er at sætte 15-20 % af udviklingsprisen af om året til vedligehold og mindre forbedringer. Det er et groft skøn, og det afhænger meget af hvor meget du vil udvikle videre. I min guide til prisen på drift og vedligehold af en webapp gennemgår jeg hvad der indgår.

Hvornår du ikke skal få bygget en webapp

Jeg lever af at bygge webapps, men det er ikke altid det rigtige svar. Her er tre situationer hvor jeg typisk vil fraråde det:

  • Når et standardsystem dækker det meste. Løser et SaaS-produkt 80 % af dit behov til en månedlig pris, er det næsten altid billigere end at bygge selv, også over flere år. Tilpas din proces til værktøjet, før du tilpasser et værktøj til din proces.
  • Når behovet ikke er afprøvet. Ved du ikke om kunderne vil bruge løsningen, så start med noget mindre, fx et no-code-værktøj som Airtable eller en enkel første version. Se hvad en MVP realistisk koster, hvis du overvejer den vej.
  • Når ingen hos dig har tid. En webapp kræver løbende beslutninger fra din side. Uden en fast kontaktperson bliver projektet både dyrere og langsommere, uanset hvem der bygger det.

At få bygget sin egen løsning betaler sig typisk først, når processen er en del af det der gør din forretning anderledes, eller når omvejene i standardsystemerne koster dine medarbejdere timer hver uge.

Sådan får du en pris du kan budgettere efter

  1. Beskriv problemet og ikke løsningen. Hvem skal bruge webappen, hvad gør de i dag, og hvad koster det dig? Det er lettere at prissætte præcist end en liste med 40 funktioner.
  2. Prioritér hårdt. Del dine ønsker op i "skal med i første version" og "kan vente". Det er den hurtigste måde at flytte prisen ned i intervallet.
  3. Start med et forprojekt. Ved større projekter anbefaler jeg et kort, betalt forprojekt til fast pris, hvor omfang, integrationer og risici bliver afklaret, før der bygges. Så bliver det endelige tilbud et kvalificeret skøn i stedet for et gæt.
  4. Bed om pris pr. fase. En fast pris på første version og en klar aftale om hvad der sker bagefter er lettere at styre end ét stort tal for det hele.
  5. Tjek hvad der ikke er med. Test, hosting, overdragelse og vedligehold skal stå et sted i tilbuddet, også hvis svaret er "ikke inkluderet".

Sådan arbejder jeg selv: du taler direkte med mig som udvikler, koden er din fra første dag, og du får svar inden for én arbejdsdag. På siden om udvikling af webapps og platforme kan du se hvordan et forløb ser ud.

Ofte stillede spørgsmål

Kan jeg få en webapp for under 50.000 kr.?

Det er muligt, men kun hvis opgaven er meget afgrænset, fx et simpelt internt værktøj med ét formål og ingen integrationer. Til den pris får du sjældent login for kunder, betaling eller et unikt design. Er budgettet stramt, er et standardsystem eller et no-code-værktøj ofte et bedre sted at starte. Så kan du få bygget noget selv, når behovet er afprøvet.

Bliver det billigere at få bygget en webapp med AI-værktøjer i 2026?

Lidt, men mindre end mange tror. AI-værktøjer gør det hurtigere at skrive standardkode og prototyper, og den besparelse bør du kunne mærke. De store poster er dog stadig afklaring, integrationer, sikkerhed, test og ansvaret for at løsningen virker i drift. Tilbyder nogen en hel kundevendt webapp til en brøkdel af intervallerne her, så spørg hvem der retter fejlene bagefter.

Er det billigere at få bygget webappen i udlandet?

Timeprisen er ofte lavere, men den samlede pris er det ikke altid. Du skal regne med mere tid til at skrive krav ned, til møder på tværs af tidszoner og til at kontrollere kvaliteten. Det kan fungere, især hvis du selv har teknisk indsigt eller en projektleder der har. Uden det flytter udgiften typisk fra timeprisen over i din egen tid og i rettelser senere.

Hvad gør jeg hvis budgettet ikke rækker til det hele?

Byg i faser. Find den mindste version der løser det vigtigste problem for de vigtigste brugere, og få den i drift først. Så kan du bruge resten af budgettet på det brugerne faktisk efterspørger i stedet for det du gættede på fra start. Bed din udvikler om at markere hvilke ønsker der koster mest, så du kan vælge med åbne øjne.