Most conversations about custom software focus on the build: what it costs, how long it takes, who builds it. Far fewer focus on what happens after go-live. That's a problem, because software isn't a product you buy once — it's something you own and run for years.
The build is maybe 60–70% of the total cost of ownership over a system's lifetime. The rest is maintenance and support. If you don't budget for it, you'll feel it within the first year.
Maintenance isn't just fixing bugs
When people hear "maintenance" they think of bug fixes. That's part of it, but the smaller part. Four different things hide under the word:
- Corrective — Fixing bugs that surface once real users hit the software in ways you didn't test for.
- Adaptive — Keeping the software working as the world around it changes: a third-party API updates, a browser changes behaviour, a tax rule changes, an OS ships a new version.
- Preventive — Updating dependencies, patching security issues and cleaning up small problems before they become big ones. This is the part that stops technical debt from piling up.
- Evolutive — Small improvements and new features as you learn how people actually use the system.
Skip the middle two and your software slowly rots — not because anyone touched it, but because everything around it kept moving.
Why "we'll just leave it alone" doesn't work
The most common assumption I hear: "Once it's built and working, we don't need to touch it." It sounds reasonable. It isn't.
A modern application is roughly 80% third-party libraries. Those libraries release updates constantly, and some of those updates close security vulnerabilities. Leave them untouched for two years and you're running known, published holes — exactly the kind of thing covered in security and GDPR basics. Meanwhile the payment provider you integrated deprecates the API version you used, and one morning checkout stops working.
Software that's "left alone" doesn't stay the same. It degrades.
What maintenance actually costs
There are two separate cost lines: hosting and maintenance.
Hosting and infrastructure are usually modest: €50–€500 per month for most business applications, depending on traffic, data volume and uptime requirements. A small internal tool sits at the low end; a customer-facing platform with real load sits higher.
Maintenance and support follow a well-known rule of thumb: budget 15–20% of the original build cost per year. For a €40,000 system, that's €6,000–€8,000 annually. That covers dependency updates, security patches, monitoring, small fixes and a defined amount of support.
That percentage isn't a tax — it's what keeps the asset working. A €40,000 system that fails in year two because nobody patched it costs far more to revive than €7,000 a year would have.
Three ways to organise support
You don't need the same arrangement for every system. The three common models:
- Monthly retainer — A fixed monthly fee (commonly €300–€1,500 depending on scope) for a set number of hours, guaranteed response times and proactive updates. Predictable, and the best fit for software your business depends on daily.
- Ad-hoc (time and materials) — You pay per hour (€80–€130 is typical) when something needs doing. Cheaper if the software is stable and non-critical, but response isn't guaranteed — you're in the queue behind everyone else.
- In-house — Once you run several systems and need continuous changes, hiring starts to make sense. Below that threshold, a retainer with a studio is usually cheaper than a salary.
What to agree before you go live
The worst time to discuss support is the day something breaks. Sort these out before launch:
- Response and resolution times — How fast does someone react to a critical issue versus a minor one? "Critical" (the system is down) might be hours; "minor" (a cosmetic bug) might be the next sprint.
- What counts as a bug vs. a new feature — Bugs are fixed under maintenance; new features are billed separately. Define the line clearly so there's no argument later.
- Who has access to what — You should own your code, your hosting accounts and your domains. If a supplier holds all the keys, you're locked in.
- Documentation and handover — Enough that another developer could take over. This is your insurance against depending on one person.
- Monitoring and alerting — You want to hear about a problem from your monitoring, not from an angry customer.
Maintenance is the cheapest insurance you'll buy
Done well, maintenance is unglamorous and quiet: dependencies stay current, security holes get closed before anyone exploits them, small issues get fixed before they spread. The bill is predictable and modest. Done badly — or not at all — you trade a few thousand euros a year for a five-figure emergency rebuild and a stretch of downtime at the worst possible moment.
It's the same logic as building maintenance. Nobody notices the year you keep up with it. Everybody notices the year you don't.
Want to know what ongoing support should look like for your software?
Tell me what you're running (or planning to build), how critical it is and how many people depend on it. I'll give you a realistic picture of the hosting and maintenance costs, and which support model fits — alongside what the build itself typically costs. No obligation, just a clear answer. Get in touch.