A business called me eighteen months after their site went live, because it had stopped taking payments overnight. I hadn’t built it. An agency had, as a WordPress site, and then that agency had gone quiet and eventually vanished. As far as the owners were concerned there was nothing to worry about, because in their heads it was just a website, and websites don’t break. Nobody had touched the code. No deploy, no config change, nothing. The payment provider had retired the old version of the integration the site relied on, warned about it for a year in emails that went to an inbox nobody read anymore, and then switched it off.
That’s the part almost nobody budgets for. After launching their product a business points its attention where it’s needed next, more customers, the next feature, actually growing, and assumes the software will keep running itself in the background. It won’t.
Software you never touch still rots.
The “launch = finished” myth
I understand where the myth comes from. Most of what you buy works like a printer. You run it until it breaks, and when it breaks you don’t repair it, you replace it, because the repair costs more than a new one. So you never really maintain a printer. You just replace it on the day it dies, and until then you don’t think about it at all.
Software works more like your grandfather’s classic car. You can’t throw it out and buy an identical fresh one, that’s a bad financial decision, and you won’t get the same exact thing anyway. And waiting for it to break before you spend anything is the most expensive way to own it. Small, steady, boring upkeep costs less than the emergency you get without it.
The reason is that software never sits still, even when you do. It runs on top of other people’s software that keeps shifting underneath it, talks to services run by companies that change their minds, and lives on a network full of people trying to break in. Think of it like a boat in the water: leave it untended and it rots from the waterline down, whether or not anyone is aboard.
This is also the answer to “why don’t we just build everything ourselves and own the whole stack?” You can, but every piece you build is another boat you now have to keep afloat. Owning more software means maintaining more software, forever. It’s one of the arguments for renting the parts that aren’t your core business. I wrote about where owning it is worth it if you want the longer version.
How stillness ruins software
Say you freeze the code completely. Not one line changes for two years. Here’s what happens anyway.
- Security holes get discovered. A library that was safe on launch day isn’t safe forever. Vulnerabilities are found in old code constantly. The code didn’t change, but the list of known ways to attack it grew, and it grows every month. If you struggle to believe this, look at the WordPress ecosystem’s vulnerabilities.
- The platforms move. Browsers update. Phone operating systems force new requirements on apps or they get pulled from the store. The companies hosting your software phase out the environment it runs on and eventually switch it off.
- Outside services you depend on change or vanish. Payment providers, email senders, Google login, every external service your app talks to has its own roadmap. They retire old versions. They change their terms.
- Certificates and secrets expire. The security certificate that proves your site is safe doesn’t last forever, the digital keys that connect your services need refreshing, and your domain comes up for renewal. Any one of them expiring takes a working system offline.
Not one of those is triggered by touching the code. Will someone be there to catch them before your customers do?
A frozen codebase isn’t a stable system. It’s a stable target with an expanding list of ways to knock it over.
What post launch work actually is
“Maintenance” is several different jobs:
- Bug fixes. No launch ships perfect. Real usage finds edges your testing didn’t. Some are cosmetic, others cost you customers.
- Security updates. Updating the outside code your software relies on, rotating passwords, and reacting when a vulnerability turns up in something you use. Most people underestimate this, but it shows up as a data breach, sometimes along with fines and lost customers.
- Staying up to date. Keeping the building blocks your software is made of current, so you’re never more than a small step from the latest version. Eventually the version you’re on stops getting security updates. Skip it for two years and the small step becomes a full rewrite, because you’re catching up on several updates all at once, each one changing how things work.
- Operations. Keeping an eye on the servers, the database, the backups, the monitoring. Making sure the thing is actually up, that you’d know if it went down, and that you could recover if it did. Quiet until the day it’s the only thing that matters. This is the work of running the system. The servers it runs on are a separate monthly bill, and that’s a topic of its own.
Budgeting for the years after launch
So, you might be asking: “what does all of this cost?”
From my own experience: budget somewhere around 15% to 25% per year of the original development cost to keep the system running and healthy. I’d treat it as a sanity check rather than a number set in stone.
Here’s what it looks like on real projects:
- A €20k internal tool, used by a dozen staff, with two integrations. Realistically the low end or below, maybe €2k to €4k a year. Not much moves underneath it, and nobody loses money if it’s down for an afternoon.
- A €60k customer facing app that takes payments, with a handful of integrations and real uptime expectations. Comfortably the middle to high end, roughly €9k to €15k a year, because every payment and login integration is a moving part someone else controls, and downtime costs real sales.
- A €150k platform in a regulated space, higher traffic, tight compliance. Often above the range, because the security and compliance upkeep alone is a standing cost before you fix a single bug.
A plan with a big number for building it and a zero for keeping it alive is an unfinished plan, and that zero is usually what ends up costing the most.
None of this is money down the drain. Skipping it doesn’t remove the cost, it just delays it, and it comes back larger. Think of the oil changes on a car: unremarkable when you do them on time and unforgettable after two years of neglecting them.
Retainer, on demand, or handover
There are three ways to actually structure who does the ongoing work, and the right one depends on your team and how much the system matters.
The retainer
You pay a fixed monthly amount and the maintainer keeps the system healthy, usually while handling a steady stream of small changes. Predictable cost, a known person who already understands your system, and someone actively watching rather than waiting for you to notice a problem. This is what I usually recommend for a system the business depends on, because the whole point is that it needs doing whether or not anything visibly broke this month.
On demand
No monthly fee. You call when something breaks or you need a change, and you pay for the time. It’s cheaper, but the catch is twofold:
- There’s no guaranteed response, so if you call during a busy period you’ll have to wait your turn behind the clients on a retainer.
- Nobody is doing the invisible upkeep, so the security patches and dependency updates don’t happen, and you find out how bad it is at the worst possible moment.
I only recommend on demand for genuinely low stakes systems. An internal tool, something with no sensitive data, somewhere a day of downtime or a slow fix costs you nothing you’d actually miss.
Handover to in house
You take it in house. Your own developers own it going forward. This is the right long term answer for plenty of companies, especially once the software is central enough to justify a full time person. It only works if the handover is real. Documentation, access to every account and credential, a walkthrough of how the thing is built and deployed, and an overlap period where the person who built it is still reachable. A real handover isn’t just a zip of the code and a “good luck”. I’ve been hired to clean up several that were.
Many businesses move through these over time. Retainer right after launch, when the system is new and the knowledge lives entirely with the builder, then a handover once the software is important enough to justify the cost. The mistake is ending up on “on demand” by accident rather than choosing it. That’s what happens when no maintenance arrangement ever gets signed, or when nobody involved sees software as a thing that needs tending in the first place.
Questions to settle before you launch
The cheapest time to sort out the maintenance arrangement is before day one, while you still have the developer’s full attention and leverage. By the time something’s broken, you’re negotiating from the weak side.
- Who fixes it when it breaks at 9am on a Tuesday, and who at 2am on a Sunday? If the answer is unclear, you don’t have a maintenance plan.
- Is there monitoring, and who gets the alert? You don’t want to hear that the system is down from an angry customer. Confirm something is watching, and that it will alert a human who’ll act on it.
- What’s the backup and recovery plan, and has anyone tested restoring from it? Testing a backup is why you have one in the first place.
- What does it cost, roughly, and in which structure? Retainer, on demand, or a handover. Have that agreed before you sign, so it’s a decision and not a surprise.
- If I want to leave, what do I need to walk away with? The code, the documentation, the deployment setup, the access. Knowing the answer before you need it is the difference between a handover and a hostage situation.
The takeaway
Launch isn’t the day your software is finished. It’s the day it’s in the best shape it will ever be by accident, fresh and clean because nobody has found the cracks yet. From there the direction is mostly your choice. Left alone, it drifts downhill. But tended properly, it goes the other way. Little by little it becomes a better piece of software than the one you launched, steadier, better fitted to how the business actually works, less likely to surprise you.
Good maintenance isn’t damage control. It’s how software gets better.
Neglect is what turns the thing you built into the thing I get hired to rescue. The businesses that budget for the years after launch, decide who owns the software, and settle these questions before they go live are the ones that never reach out in a panic.
If you’re planning to build something and there’s a confident number next to “development” and a blank next to “everything after,” or you launched a while ago and you’re not sure who’s keeping the thing afloat, this is the conversation worth having before something forces it.