De skjulte omkostninger ved softwareprojekter

En typisk femårig TCO for en skræddersyet dansk enterprise-web-applikation ser groft ud sådan her: byg er 30–50 %, løbende engineering er 25–35 %, hosting og SaaS er 10–20 %, sikkerhed og compliance er 5–10 %, og "absorberede" omkostninger (langsomme funktioner, support-overhead, opportunity cost) er resten. Headline-tallet på byggetilbuddet er den mindste linjepost over systemets levetid.

"Vi vedligeholder det selv"-planen er reel, men den har en pris. Bug-triage, sikkerhedspatching, dependency-opgraderinger, browser-kompatibilitet, OS-migrationer, framework-versions-bumps. Intet af det står på byggetilbuddet. Det hele står på din faktura de næste fem år.

Planlæg minimum 15–25 % af den oprindelige byggeomkostning pr. år som løbende engineering, afhængigt af hvor eksponeret systemet er for ekstern ændring (browsere, OS-opdateringer, regulatoriske ændringer, tredjeparts-API-churn). For et byg på 2.000.000 DKK er det 300.000–500.000 DKK/år, hvert år, bare for at undgå at det rådner.

Hostingregningen er sjældent den største linje, men den er den letteste at miste overblik over. Vercel, AWS, overvågning, fejlrapportering, feature flags, søgning, e-mail, analyse, CMS, auth — hver starter som et lille månedligt abonnement og vokser i stilhed. Et typisk mellemstort enterprise-webprodukt bærer 8–15 SaaS-linjeposter ved år tre.

• Auditér SaaS-listen kvartalsvis. Halvdelen af dem har free tiers, du i stilhed er vokset fra.
• Forhandl årsaftaler, når brugen stabiliseres; listepriser er et udgangspunkt.
• Hold øje med pris pr. seat, når dit team vokser; omkostningskurven er ikke flad.
• Egress er den tavse dræber på cloud-regninger. Mål den, før du skalerer.

Hver npm-pakke, hvert eksternt bibliotek, hvert SDK er en vedligeholdelseskontrakt, du ikke skrev under. De fleste er gratis i penge og dyre i tid: sikkerheds-CVE'er, breaking changes på majors, deprecations-cyklusser, forladte projekter.

En moderne Next.js-app leveres med hundredvis af transitive dependencies på dag ét. Hver er en sandsynlighed for ikke-planlagt engineering-arbejde over fem år. Den billigste version af denne omkostning er at starte med færre; den næstbilligste er en klar politik for, hvilke dependencies du stoler på, og hvilke du ikke gør.

Når bureauet, der byggede systemet, forlader, betaler det næste team vidensomkostningen. Er dokumentationsunderskuddet stort, betyder det at gen-lære systemet fra koden, nogle gange ved at gen-implementere funktioner, der allerede eksisterer, fordi ingen vidste det. Omkostningen viser sig som oppustede estimater, oversete edge cases og konservative afvisninger af at ændre ting, der trygt kunne ændres.

Den billigste forsikring er at gøre dokumentation til en leverance. ADR'er (architecture decision records), runbooks for hver tilbagevendende operationel opgave, et arkitekturdiagram der matcher virkeligheden, og en README der lader en ny seniorudvikler levere en lille ændring i sin første uge. Intet af det er "dokumentationsteater." Det betaler sig tilbage første gang, du onboarder.

GDPR, CSRD, EAA (European Accessibility Act), DSA, NIS2, branchespecifik regulering. Compliance er ikke en engangs-linjepost; det er en evig en. Den tilgængelighedsaudit, du ikke laver i dag, er det retssagsbudget, du holder i morgen. Den sikkerhedsreview, du springer over, er den breach-disclosure, du skriver om to år.

• Planlæg én tilgængelighedsaudit pr. major-udgivelse, plus regressionstjek i CI.
• Planlæg én ekstern sikkerhedsreview om året, mere hvis du håndterer regulerede data.
• Tilmeld dig sikkerheds-advisories for hver dependency på den kritiske sti.
• Hav en skriftlig incident response-plan. Første gang du skal bruge den, er ikke tidspunktet at skrive den.