Software maintenance costs: what an app or website really costs per year

Launch day is the cheapest day of your product's life. Everything after it costs money forever: servers, certificates, OS updates, store reviews, dependency patches, backups, and the slow accumulation of small fixes that keep software aligned with a world that keeps moving. Buyers routinely budget the build to the euro and the aftermath to zero, then act surprised when year two arrives with invoices.

This guide prices the afterlife honestly: what each running-cost category costs, why the 15-20% rule exists, and which products break it in each direction.

The 15-20% rule and what it covers

Industry guides converge on one budgeting rule: plan 15-20% of the initial build cost per year for maintenance. A EUR60,000 app needs roughly EUR9,000-12,000 a year; a EUR10,000 website needs EUR1,500-2,000. The rule survives because the underlying work scales with build complexity: bigger builds have more dependencies, more integrations, more OS surface, and more users finding edge cases.

What the percentage buys, category by category:

Hosting and infrastructure, typically EUR10-100 a month for websites and EUR50-500 for apps with real backends. EU hosting on providers like Hetzner or AWS Frankfurt adds no meaningful premium over US equivalents; the compliance posture is the point, not the price. Costs spike only when engineering is neglected: unoptimized queries, missing caching, runaway API usage.

Updates and compliance, the largest share. Dependencies need patching, iOS and Android ship OS versions yearly that break untested paths, and both app stores tighten requirements on privacy manifests, SDK versions, and target API levels every cycle. For German products add the moving regulatory surface: e-invoicing obligations phasing in through 2028 per the XRechnung coordination office, and BFSG accessibility duties for consumer products since June 2025.

Monitoring, backups, and small fixes. Uptime monitoring, automated backups with tested restores, certificate renewals, and the steady drip of minor corrections: a confusing error message, a broken edge case, a copy change. Individually trivial, collectively the difference between software that feels alive and software that feels abandoned.

Which products break the rule

The rule is a median, and medians hide a spread. Three product shapes land reliably above 20%.

Anything with money attached: shops, marketplaces, subscription products. Payment provider updates, fraud patterns, tax rule changes, and dispute handling create continuous work that never appears in the build quote. Budget 20-25% and treat it as cost of revenue, not overhead.

Anything with third-party integrations: ERP links, CRM syncs, DATEV pipelines. Every external system changes its API on its own schedule, and each change becomes your incident. Count integrations when budgeting maintenance exactly as you counted them when budgeting the build; our MVP cost guide explains why each one beyond the first two adds real money.

Anything regulated: health, finance, children's products, public sector. Audit trails, penetration tests, documentation duties, and certification renewals are recurring by law. Maintenance here is a compliance function with engineering attached, and underbudgeting it is a legal risk before it is a technical one.

Below the rule sit static marketing sites and simple content apps: few dependencies, no user data flows, no store presence. Five to ten percent covers them, mostly hosting and occasional updates. If a vendor quotes 20% maintenance on a brochure site, get a second quote.

Retainer or pay per fix

For anything business-critical, a small monthly retainer beats pay-per-fix on every dimension that matters. It buys monitoring with someone watching, guaranteed response times, and crucially, a team that already knows your codebase when it breaks at the worst possible moment. The retainer is not mostly the hours; it is the standing relationship.

Pay-per-fix wins for brochure sites and side projects where a day of downtime costs nothing and the codebase is simple enough that any competent developer can orient in an hour. The failure mode is the inverse: a complex product on pay-per-fix means every incident starts with a stranger reading your code at emergency rates.

Either way, insist on the unglamorous fundamentals in writing: work happens in your repositories, staging mirrors production, backups restore on a tested schedule, and documentation updates with the code. Our contract checklist covers the clauses; they matter as much for maintenance as for builds.

Budgeting maintenance before you build

The cheapest maintenance conversation happens before the first line of code, because build decisions set maintenance cost for years. A standard stack with boring technology costs less to maintain than an exotic one. Fewer integrations mean fewer future incidents. A clean data model and tested payments mean fixes take hours instead of days. When comparing build quotes, ask each vendor for their year-two estimate in the same document; vendors who cannot produce one are telling you how they think about the afterlife.

For the build side of the budget, start with app costs or website costs in Germany, then add the yearly share from the calculator above. And if you inherited a product whose maintenance was budgeted at zero, send the codebase: the audit is cheaper than the emergency: talk to us.