Software built — now what? Why maintenance decides whether it succeeds
by Marcel, Senior software engineer
The launch is done, the software runs, everyone's relieved — and for many that ticks the project off. This is exactly where the most expensive misconception in software development lives. An application isn't "finished" at go-live, it's only just going into service. What happens after that decides whether it's still a reliable tool in three years — or a ticking security risk nobody wants to touch anymore.
Is software finished after launch?
No. Software isn't a piece of furniture you set down once and forget, it's more like a garden: without regular care it gets overgrown. The code we write today runs on a stack of operating system, programming language, frameworks and dozens of external libraries. All of that keeps evolving — with security patches, new versions and eventually the end of support. Your application sits in that current whether you tend to it or not.
So the short answer is: launch is the finish line of development, but the starting line of operation. And operation needs care.
What good software maintenance covers
Maintenance isn't "taking a look now and then". It has five clear components that work together:
- Security updates. Vulnerabilities are constantly found and closed in frameworks and libraries. Maintenance means applying those patches promptly, before someone exploits them.
- Keeping dependencies current. Every modern application uses other people's code — packages for authentication, image processing, payments and much more. These dependencies need regular updates, otherwise they age together and the jump eventually becomes open-heart surgery.
- Bug fixes. Even cleanly built software has rough edges that only show up in real operation. Fixing them quickly keeps the software usable — and your users happy.
- Further development. Your business doesn't stand still. New requirements, new processes, new user requests: an application that grows with you stays a tool. One that freezes becomes a brake.
- Monitoring & backups. You want to hear about problems before your customers call. Monitoring availability, errors and performance plus tested backups are the safety net that makes the difference between "brief scare" and "disaster" when it counts.
What happens if you don't maintain it?
Neglected software rarely dies with a bang. It decays gradually — and that's exactly what makes it dangerous, because the problem stays invisible for a long time.
Security holes become open doors
When a vulnerability in a widely used framework becomes public, the patch instructions double as build instructions for attackers. Automated scanners comb half the internet for exactly these unpatched systems. An unmaintained application isn't a question of "if" but of "when" — with data loss, GDPR problems and a damaged reputation as the consequence.
Technical debt grows with compound interest
"Technical debt" is more than a metaphor: if you postpone an update by a year, you're not pushing one update ahead of you but often five that depend on each other. A small, regular effort turns into a big, risky migration project. We see this over and over in our projects — an application that "ran" for years and suddenly demands disproportionate effort for every small change, because the foundation is outdated. It's the same pattern we described in our piece on replacing legacy software.
- of software lifecycle costs arise after launch, in operation and maintenance
- approx. 60–80%
- is what a security update costs — compared to the fallout from an exploited hole
- €0
You lose your ability to act
Perhaps the most expensive problem: at some point nobody dares touch anything. The original developer is gone, the versions are so old that current tools no longer fit, and every change could knock something else over. An application that was supposed to be your competitive advantage becomes a millstone.
How much maintenance does my software need?
The honest answer: it depends on how critical the application is for you. An internal report that runs once a month needs less attention than a customer portal your revenue depends on. As a rough guide from practice: for ongoing care of an actively used custom application, you should budget an annual figure of roughly 15 to 20 percent of the original development cost. That sounds like a lot, but it's almost always cheaper than the alternative — an emergency refactor or a complete rebuild because nothing happened for too long.
Top tip
Plan for maintenance from the start — not once things are on fire. If you account for the maintenance budget in your very first calculation, you make smarter decisions when picking your technology and avoid nasty surprises in the second year of operation.
How do you plan and budget support sensibly?
You don't have to solve everything at once. It's enough to decide a few things deliberately:
- Clarify responsibility. Who takes care of it? An in-house team, your service provider, or a mix? The main thing is that it isn't "somehow nobody".
- Set maintenance windows. Regular, small update rounds instead of rare big pushes. That keeps the effort low and predictable.
- Set up monitoring. Measure first, then know. Without monitoring you find out about problems last — namely when customers complain.
- Test backups, don't just create them. A backup that can't be restored when it matters isn't a backup. Test the recovery.
- Pick a model. Some want a fixed maintenance contract with a clear scope, others prefer flexible help on call. Both are legitimate — what matters is that there's a model at all.
These considerations apply to every application, by the way, not just custom software: a website, an online shop or an app need exactly the same attention — updates, monitoring, backups, further development.
How we approach maintenance
We build software from the start so it stays maintainable: cleanly structured, documented and tested. That's half the battle, because poorly kept code is expensive to maintain no matter how good the person maintaining it is. In ongoing operation we keep dependencies current, apply security updates promptly, fix bugs and develop your application further where your business needs it — with monitoring and backups as the safety net in the background.
And we adapt to you: as ongoing support with a fixed scope, or simply on call. You get a direct contact instead of a hotline, and you know where you stand up front.
You've had software built and you're wondering who takes care of it going forward — or who can take over an existing application nobody is currently maintaining? Let's take a look together in a free initial call, honest and without obligation. We'll tell you what's genuinely necessary and what can wait.