What software costs after launch: maintenance, hosting and updates

Everyone budgets for building. Far fewer people budget for owning. Then the first hosting bill arrives, a browser update breaks a page, and the project that was "finished" turns out to need attention every month.

That is not a sign something went wrong. It is just what software is. It is closer to a vehicle than a piece of furniture: it needs fuel, servicing, and the odd repair, or it slowly stops working.

The four things you are paying for

1. Hosting and infrastructure. Your software has to live somewhere. Servers, databases, file storage, backups, and domain names all have recurring costs. They tend to grow as your usage grows.

2. Third-party services. Payments, email delivery, SMS, maps, analytics, AI tools. Most are charged per use or per month. A feature that costs pennies in testing can add up at volume. See adding payments for an example of what to watch.

3. Maintenance. The unseen work that keeps things healthy:

• Applying security patches.
• Updating the pieces your software is built on, which get new versions regularly.
• Fixing bugs that show up as real people use it.
• Keeping up with changes from phone makers, browsers, and payment providers.
• Monitoring, so problems are noticed before customers report them.

4. Improvements. Once people use the product, they ask for changes. New reports, different workflows, extra integrations. This is the good kind of cost, because it means the software is alive.

Why it can't be skipped

Neglected software decays quietly. Components go out of date and stop getting security fixes. A third party changes its rules and an integration breaks. Browsers move on. For a while nothing seems wrong, and then something important fails on a busy day.

The longer you leave it, the more it costs to catch up, and the riskier the catch-up becomes. That is how companies end up with the fragile systems we describe in old software still running your business.

How to budget

There is no universal figure, and anyone quoting you one without looking at your project is guessing. But you can reason about it:

• Separate fixed from variable. Hosting and subscriptions are fairly predictable. Improvements depend on your appetite.
• Plan for a recurring allowance. Many teams set aside a monthly amount for upkeep and small changes, rather than treating each as a new project.
• Ask for estimates upfront. Any serious proposal should say what running costs look like after launch. If it does not, ask.
• Add a cushion in year one. The first months after launch are when real use uncovers things.

Think of it as part of the price of the software, not an extra. It belongs in the same conversation as what drives the build cost.

Ways to keep costs sensible

• Choose boring, widely-used technology. It is easier and cheaper to find people who can maintain it.
• Keep it simple. Every feature you add is a feature you maintain. Resist adding things that are rarely used.
• Use managed services where it makes sense. Paying a provider to handle something can be cheaper than doing it yourself.
• Document things. Notes on how it is set up and why decisions were made save hours later.
• Own your accounts. Hosting, domains, and code repositories should be in your name, so you are never locked out.
• Review regularly. Once a quarter, look at what you are paying for and cut what is unused.

Support: who do you call?

Decide in advance who handles problems. Options include an ongoing agreement with the team that built it, a retainer for a set number of hours, or paying as issues come up. Each works. The one that does not work is nobody being responsible.

Ask what response looks like: how quickly someone will answer, and what counts as urgent. For software that earns you money, that matters.

The reassuring part

Maintenance costs, handled well, are modest relative to the value good software delivers. They are also much easier to manage when you have planned for them. The bad surprises come from ignoring the topic until something breaks.

What a typical year of upkeep looks like

It helps to picture the calendar rather than a lump sum. Over a year, a live system usually sees:

Constant background work. Monitoring, automated backups, and small fixes. This is the quiet part, and when it is done well you hardly notice it.

Regular updates. The components your software is built on release new versions several times a year. Some include security fixes that should be applied promptly. Others are bigger changes that need testing before they go live.

Occasional outside shocks. A payment provider changes its requirements. A browser release alters how something behaves. An email service tightens its rules and your messages start landing in spam. None of these is your fault, and all of them need someone to respond.

One or two bigger improvements. Customers and staff ask for new things. Some are small tweaks; some are real features.

The odd emergency. A server problem, a surprise spike in traffic, a bug that only appears under unusual conditions. You cannot predict which, but you can be ready for something.

Thinking in these categories makes budgeting more realistic, because you can allocate time to each rather than hoping nothing happens.

Keeping the lights on versus moving forward

Some of the cost is for stability, and some is for growth. It is useful to keep them separate in your mind and on paper.

• Run costs keep the existing product working. They are somewhat predictable and should be treated as non-negotiable.
• Change costs add or improve things. They are discretionary, and you can speed them up, slow them down, or pause them.

Many disputes about software spending come from these two getting mixed. A team asked to make a big new feature while also keeping everything stable, without extra time, will do one of them poorly. Be clear which bucket a piece of work belongs to.

Questions to ask before you sign

When you are choosing who will build and look after your software, ask:

1. What does ongoing support include? Bug fixes, updates, monitoring, or only emergencies?
2. How is it priced? A fixed monthly amount, a block of hours, or per request?
3. What response times can I expect? And what counts as an emergency?
4. Who will do the work? The same team that built it, or someone new who will need to learn it?
5. What happens if we part ways? How easily can another team take over? This is where good documentation and clear ownership pay off.

An honest provider will answer these plainly, and will be glad you asked.

Tracking what you are paying for

Set up a simple list of every recurring cost tied to the software: hosting, domain names, email sending, payment fees, monitoring tools, licenses, and anything else. Put the renewal dates in a calendar.

Review it every few months. You will often find services left running after they stopped being needed, or plans that no longer suit your usage. Small savings, found regularly, add up. And knowing what is behind each charge makes it much easier to decide where to cut and where not to.

When the numbers surprise you

If running costs climb faster than expected, look for the cause before reacting. It might be healthy, such as more customers using the product. It might be a fixable inefficiency, like a process that makes far more requests than it needs to. Or it might be a sign that something has grown too complicated.

Whichever it is, raise it early with whoever looks after the system. Costs that are discussed openly can be managed. Costs that are ignored tend to arrive as a shock, and shocks make for poor decisions.

Documentation is cheaper than memory

One of the best ways to hold down long-term costs is to make sure the system is understood by more than one person. A short document describing how it is set up, how to deploy a change, and where the important accounts live can save hours every time someone new touches it.

Ask for this as part of the project, and keep it up to date. It reduces your dependence on any single developer and makes switching teams, if you ever need to, far less painful.

If you are planning a project and want a clear picture of the running costs from the start, talk to us. We will lay out the whole lifecycle, not just the build.