What Software Maintenance Costs After Launch: A DACH SaaS Benchmark

Launch is not the end of a software budget. It is the moment the budget changes shape. Before launch, the money buys product discovery, implementation, QA and deployment. After launch, the money buys continuity: bug fixes, dependency upgrades, cloud and observability, security, compliance, support, product iteration and emergency work.

This article is deliberately separate from our custom software development guide. That guide answers the build-cost intent. This benchmark answers the post-launch intent: what does software maintenance cost per year after a SaaS product is live?

The benchmark answer

For a DACH SaaS product, budget roughly 18-30% of the original build cost per year after launch if the product is still evolving. A quiet, low-risk internal app can sit closer to 10-16%. A regulated, integration-heavy or fast-growing SaaS product can reach 35-60% when compliance, support, security and product iteration are all active.

In our directional benchmark of 24 DACH SaaS and SaaS-like products maintained between 2023 and mid-2026, the median annual maintenance spend was 24% of original build cost in year one, 21% in year two and 26% in year three. The year-three rise was not because software magically decays on its birthday. It was caused by framework major versions, cloud growth, accumulated product requests, compliance evidence, security findings and integrations that had become business-critical.

What counts as software maintenance?

ISO/IEC maintenance language separates corrective, adaptive, perfective and preventive maintenance. That maps well to real SaaS budgets: corrective work fixes bugs, adaptive work keeps the product usable as browsers, APIs, devices and laws change, perfective work improves product and maintainability, and preventive work reduces future risk. The messy reality is that one ticket often spans all four.

Year one, two and three broken down

The percentage split below is a planning benchmark, not a universal law. It assumes a product that is live, used, and still worth improving, but not undergoing a full v2 rebuild.

Interactive maintenance calculator

Use this calculator for a first board-level estimate. It starts from the benchmark above and adjusts for product type, compliance pressure, usage, support load and technical debt.

How to read the calculator

The number is an annual product operating budget. It should include enough engineering time to keep the software useful and safe. It should not silently absorb a new product line, a full redesign, a data migration, a SOC 2 project or a rewrite. Those belong in separate scopes.

Why dependencies became a real budget line

Modern SaaS products are partly custom code and partly supply chain: frameworks, packages, SDKs, build tools, container images, cloud services and APIs. The long tail is the cost. Sonatype's 2025 Log4j data, reported by ITPro, found that around 13% of global Log4j downloads still contained the Log4Shell vulnerability even four years after disclosure, while the same reporting notes Sonatype's claim that around 95% of vulnerable open-source component downloads already had a fixed version available. The lesson is uncomfortable: vulnerable dependencies often persist because nobody owns maintenance.

That is why the yearly maintenance budget should include dependency windows, not just security alerts. A monthly patch window handles routine updates. A quarterly upgrade window handles framework, runtime and SDK changes. A yearly architecture review asks whether the stack still has maintainers, hiring supply and a credible upgrade path.

Cloud and observability are not optional after launch

Pre-launch teams often underbudget operations because the product is still quiet. After launch, traffic, logs, traces, metrics, storage, backups, queues, email, search, AI APIs and third-party monitoring become recurring cost drivers. This is not only a cloud invoice problem. It is an ownership problem: every alert, dashboard, retention rule and runbook needs someone who knows what action to take.

For a small SaaS product, cloud and observability may be a few hundred euros per month. For a data-heavy, AI-heavy or audit-heavy product, logs and traces alone can become a serious line item. The budget should therefore contain both provider spend and engineering time to reduce waste: retention tuning, index control, sampling, right-sizing, slow-query fixes and cost alerts.

Security and compliance are now lifecycle work

GDPR already makes data protection by design a live obligation, not a launch task. NIS2, the Cyber Resilience Act and the EU AI Act add more lifecycle pressure for products in affected categories. The exact applicability depends on product, sector and role, but the engineering pattern is stable: keep an asset inventory, know your dependencies, patch vulnerabilities, retain evidence, monitor incidents and document decisions.

The Cyber Resilience Act is especially relevant to software maintenance because it moves security responsibility toward the whole support period for products with digital elements. Even where a SaaS product is not directly in scope, enterprise buyers increasingly ask CRA-style questions: how long do you support this product, how do you handle vulnerabilities, and can you prove updates are delivered safely?

Support is where hidden maintenance becomes visible

Support tickets are not noise. They are the product telling you where the system is ambiguous, brittle or under-documented. In our benchmark, products with no technical support owner paid twice: first through slow user triage, then through larger engineering batches when issues finally reached the team with poor reproduction detail.

A healthy maintenance setup creates a triage lane: severity, reproduction steps, affected account, logs, likely owner, workaround, fix decision and follow-up. That is cheap compared with having senior engineers rediscover context every time a customer says something is broken.

Product iteration is maintenance, but not all maintenance is product iteration

This is the cannibalization trap in cost content. A build-cost guide should answer "what does it cost to create the product?" A maintenance benchmark should answer "what does it cost to keep the product useful after it exists?" Product iteration sits between those questions. Small workflow improvements, UX fixes, report adjustments and conversion polish belong in maintenance. New modules, new personas, new pricing models and a mobile app beside a web product usually belong in a separate roadmap budget.

For commercial planning, the path is: custom software development for the build, software QA for confidence and regression control, and fractional CTO when the product needs operating rhythm, architecture decisions and vendor accountability.

Questions buyers ask

How much does app maintenance cost per year?

For a serious SaaS or custom web app in DACH, plan 18-30% of the original build cost per year if the product is live and still evolving. Quiet internal tools can be lower. Regulated, integration-heavy or fast-growing products can be much higher.

Is software maintenance cheaper in year two?

Often, yes, if launch defects are fixed and ownership is clear. But year two is only cheaper when dependency updates, support and security are handled continuously. If the team freezes the stack for two years, year three becomes expensive.

Should cloud costs be included in maintenance?

Yes. Cloud, observability, backups, monitoring and incident response are part of post-launch cost. They should be visible as separate lines so product work does not hide infrastructure waste.

How much emergency budget should we keep?

Keep at least 1-3% of original build cost per year as an emergency reserve, or more if downtime is expensive. Without a reserve, every urgent fix competes with roadmap work at the worst possible moment.

Sources and benchmark caveat

This benchmark is based on Wavect delivery and maintenance observations across 24 anonymized DACH SaaS and SaaS-like products, plus external evidence on maintenance categories, software supply-chain risk and EU regulatory pressure. It is directional, not a statistically representative survey. Use it to budget, then replace the assumptions with your own production data.

For maintenance categories, see ISO/IEC/IEEE 14764 and SWEBOK's software maintenance guidance. For supply-chain risk, see Sonatype's 2025 Log4j and open-source ecosystem reporting via ITPro and the SLSA adoption paper on arXiv. For EU compliance pressure, re-check the official text of the GDPR, NIS2 Directive, Cyber Resilience Act and EU AI Act. For cloud and observability, re-check current provider pricing such as AWS CloudWatch, Datadog and Sentry before committing a budget.