The hidden costs of software projects

A typical five-year TCO for a custom Danish enterprise web application looks roughly like: build is 30–50%, ongoing engineering is 25–35%, hosting and SaaS is 10–20%, security and compliance is 5–10%, and "absorbed" cost (slow features, support overhead, opportunity cost) is the rest. The headline number on the build proposal is the smallest line item over the lifetime of the system.

The "we'll maintain it ourselves" plan is real, but it has a price. Bug triage, security patching, dependency upgrades, browser compatibility, OS migrations, framework version bumps. None of this is on the build proposal. All of it is in your invoice for the next five years.

Plan for at minimum 15–25% of the original build cost per year as ongoing engineering, depending on how exposed the system is to external change (browsers, OS updates, regulatory changes, third-party API churn). For a 2.000.000 DKK build, that's 300.000–500.000 DKK/year, every year, just to keep it from rotting.

The hosting bill is rarely the biggest line, but it is the easiest to lose track of. Vercel, AWS, monitoring, error reporting, feature flags, search, email, analytics, CMS, auth — each starts as a small monthly subscription and quietly compounds. A typical mid-sized enterprise web product carries 8–15 SaaS line items by year three.

• Audit the SaaS list quarterly. Half of them have free tiers you've outgrown silently.
• Negotiate annual deals once usage stabilizes; the list price is a starting point.
• Watch for per-seat pricing as your team grows; the cost curve is not flat.
• Egress is the silent killer on cloud bills. Measure it before scaling.

Every npm package, every external library, every SDK is a maintenance contract you didn't sign. Most are free in money and expensive in time: security CVEs, breaking changes on majors, deprecation cycles, abandoned projects.

A modern Next.js app ships with hundreds of transitive dependencies on day one. Each one is a probability of unplanned engineering work over five years. The cheapest version of this cost is to start with fewer; the second cheapest is a clear policy on which dependencies you trust and which you don't.

When the agency that built the system leaves, the next team pays the knowledge cost. If the documentation deficit is large, that means re-learning the system from the code, sometimes by re-implementing features that already exist because no one knew. The cost shows up as inflated estimates, missed edge cases, and conservative refusals to change things that could safely be changed.

The cheapest insurance is to make documentation a deliverable. ADRs (architecture decision records), runbooks for every recurring operational task, an architecture diagram that matches reality, and a README that lets a new senior engineer ship a small change in their first week. None of this is "documentation theatre." It pays back the first time you onboard.

GDPR, CSRD, EAA (European Accessibility Act), DSA, NIS2, sector-specific regulation. Compliance is not a one-time line item; it is a perpetual one. The accessibility audit you don't do today is the lawsuit budget you'll hold tomorrow. The security review you skip is the breach disclosure you'll write in two years.

• Plan for one accessibility audit per major release, plus regression checks in CI.
• Plan for one external security review per year, more if you handle regulated data.
• Subscribe to the security advisories of every dependency on the critical path.
• Have a written incident response plan. The first time you need it is not the time to write it.