Ongoing software costs: maintenance, hosting and support

When companies plan a software project, the development price usually takes centre stage. Yet go-live only marks the start of the longest phase in the life of any software. In his book “Facts and Fallacies of Software Engineering”, software researcher Robert L. Glass found that maintenance typically accounts for 40 to 80 percent of total software costs. This guide explains what ongoing costs are made up of, why updates cannot be put off and how to plan these costs realistically. As of October 2026.

Hosting and infrastructure

The most obvious item is running the application on a server. Surprisingly often, it is also the smallest: according to Hetzner's price list, cloud servers with shared vCPUs start at €6.49 per month excluding VAT. For an application a business relies on, however, a single server is rarely enough. On top come automatic backups to a second location, monitoring that reports outages before customers notice them, a staging environment for new releases, plus domains and TLS certificates.

Many applications also use third-party services: email delivery, maps, payment processing, error tracking or AI models billed by usage. These costs grow with the success of the application, so they should be calculated with realistic user numbers. Apps also need developer accounts: 99 US dollars a year for the Apple Developer Program and a one-off 25 US dollars for Google Play.

Maintenance: security and updates

Much of any software consists of frameworks and libraries maintained by others – and only for a limited time. With the web framework Ruby on Rails, each release series receives bug fixes for one year and security fixes “for two years after the first release in its series”. After that, the application has to be upgraded to a newer version if it is to keep receiving security updates. Programming languages, databases and operating systems follow similar cycles.

For apps, the platforms set the pace. Since April 28, 2026, apps uploaded to App Store Connect “must be built with Xcode 26 or later” using the SDK for iOS 26. Google requires new apps and updates to target Android 16 from August 31, 2026. Existing apps that do not target at least Android 15 are no longer available to new users on newer devices. If you leave your app untouched for a few years, you may not even be able to publish a quick bug fix when it really matters.

For many companies, maintenance has also become a legal matter. Germany's NIS2 Implementation Act has been in force since December 6, 2025. It requires the companies it covers to take security measures when maintaining their IT systems, “including vulnerability management and disclosure”^* (Section 30 BSIG). An application without updates is therefore more than just a technical risk.

Support and operational responsibility

Sooner or later a service goes down, a certificate expires or an interface suddenly returns unexpected data. What matters then is that someone is responsible, knows the application and reacts quickly. This readiness costs money, even in months when nothing happens – much like insurance. How much of it you need depends on how business-critical the application is: an internal reporting tool can tolerate an outage until the next working day, a customer portal or an app for field staff cannot.

Put these expectations in writing before anything happens: who can be reached, how quickly will they respond, how often are updates applied, and how are small change requests billed? A clear agreement protects both sides from surprises.

Further development: the largest item

According to Glass, most ongoing costs are caused not by defects but by enhancements. He puts their share of maintenance costs at around 60 percent, compared with around 17 percent for bug fixing. That is good news: software that is used grows with the business. New products, locations, regulations or customer requests turn into new requirements.

Whether these changes stay affordable is decided during development. Readable code, automated tests and clean documentation keep the cost of every change low. Without them, technical debt grows year by year until even small changes take weeks. When a step-by-step modernisation pays off at that point is the subject of our article Refactoring or rewrite.

Run it yourself or outsource?

Many companies wonder whether to run their application themselves or hand operations over to a service provider. Running it in-house makes sense if you have an IT department with the right experience. But it takes more than a server: someone has to track updates, check backups, see alerts at weekends too and be covered during holidays. In smaller teams in particular, this knowledge often rests with a single person.

A provider who developed the application knows how it is built and can handle updates and bug fixing from a single source. Either way, what matters is that access credentials, documentation and source code are organised so that switching remains possible. Settling this from the outset avoids a dependency that can become expensive later on.

How to plan ongoing costs realistically

There is no flat percentage rule that fits every piece of software. A more reliable approach is an inventory: which components does the application have, which frameworks and services does it contain, and when do their support periods end? This gives you an upgrade calendar you can budget for. For infrastructure and third-party services, a projection based on expected usage is usually enough.

Separately, set aside a budget for further development that is guided by benefit rather than a fixed ratio. If you ask about hosting, maintenance and support when comparing quotes, you compare the total cost rather than just the development price. How high that price is likely to be is covered in our guides How much does an app cost?, How much does a web application cost? and How much does custom software cost?.

Conclusion: operations are part of the investment

Ongoing costs are not a sign of poor software but the price of keeping it secure, available and useful. If you plan for hosting, updates, support and further development from the start, you avoid an expensive modernisation backlog and can respond to new requirements at any time.

At 4eB, we run applications not only for clients but also for our own products Inventary and Stundenplan-Digital – containerised with Docker and Kamal, deployed automatically via GitLab CI and monitored on our own infrastructure. We bring this experience to our operations, hosting and cloud services, from initial setup to ongoing maintenance and support. Get in touch if you want to plan the ongoing costs of your software or are looking for a reliable partner to run it.

Sources

• Robert L. Glass: Facts and Fallacies of Software Engineering, Addison-Wesley, 2002
• Hetzner: Cloud Server, price list, accessed October 6, 2026
• Apple: Apple Developer Program, accessed October 6, 2026
• Google: Get started with Play Console, accessed October 6, 2026
• Ruby on Rails: Maintenance Policy, accessed October 6, 2026
• Apple: Upcoming Requirements, accessed October 6, 2026
• Android Developers: Meet Google Play's target API level requirement, accessed October 6, 2026
• Section 30 BSIG (risk management measures) as amended by the German NIS2 Implementation and Cybersecurity Strengthening Act, in force since December 6, 2025 (in German)

* Our translation of a quote from a German-language source.