Software maintenance cost: what you pay after launch

Software maintenance cost is what it takes to keep custom software running, secure and useful after launch. It has four parts: hosting and running costs, updates and security, fixes, and changes as your business changes. Each is priced differently, and the biggest variable is usually how much you ask the software to change over time.

This article explains what is in each part and what makes it larger or smaller, so you can budget for it and compare quotes. It does not give price bands, because they depend on your system and no two systems age the same way. For the cost of building, see our guide to what custom software costs.

The four parts of software maintenance cost

Hosting and running costs

Someone has to pay for the place the software lives. This usually means a hosting account, a database, file storage, automatic backups and a monitoring service that tells you if the system goes down. Many tools also charge per use: text messages, emails, maps, payment processing, or calls to an AI service.

Those per-use charges belong to the supplier, not the developer, and they grow with the number of users and messages. Ask for a list of every outside service the system uses and who holds the account. Each supplier publishes its own current prices, so check their pages instead of relying on a figure in an article.

Updates and security

Custom software is built from many components that other people maintain. Those components release fixes, including security fixes, and eventually stop being supported. Someone needs to apply updates, test that nothing broke, and move the system to newer versions before the old ones are retired.

This work is invisible when done and painful when skipped. A system left alone for several years can reach a point where updating one part requires updating everything, which costs far more than steady small updates would have. If your software holds customer or health data, the privacy rules where your customers live also set expectations about how you protect it. Those rules differ by country, so check the ones that apply to you.

Fixes and changes are not the same thing

A fix returns the software to what was agreed. A change adds something new. The distinction decides who pays.

Most builders give a warranty or support period after launch during which they fix faults at no charge. After that, fixes are normally billed. Changes are almost always billed from day one. Ask for these terms in writing, including how long the warranty runs and how a disputed item is classified.

Changes are the part you control. Every new report, rule or integration adds to what must be maintained forever. Some of them pay for themselves; some are nice to have and become permanent weight.

Worked example: a clinic booking and intake system

Take a small clinic with a custom online booking and patient intake system. The numbers below are invented to show how the parts fit together.

• Hosting and services: a fixed monthly bill that rises slightly in months with many text reminders sent.
• Updates: a few hours every quarter to apply updates and check that bookings, reminders and the link to the practice software still work.
• Fixes: in the first months, a handful of small corrections, such as a reminder that sends at the wrong time zone after daylight saving changes.
• Changes: the clinic adds a second location and a new type of appointment. That is a change, scoped and quoted on its own.

The point is the shape, not the figures. Hosting is predictable. Updates are small and regular. Fixes shrink as the system settles. Changes are lumpy and driven by decisions the clinic makes.

How maintenance is charged

• Retainer. A fixed monthly fee covering hosting management, updates, monitoring and a block of support time. It suits software people rely on daily because you get a faster response and a steady bill.
• Time and materials. You pay for hours as used. It suits stable software that rarely needs attention, but a problem during a busy week may wait for the developer’s calendar.
• Pay as you go with a minimum. A small monthly fee keeps someone responsible for monitoring and updates, and anything bigger is quoted.
• Do it yourself. Possible if you have a technical person on staff. You take on the monitoring, updates and security responsibility, and the developer’s warranty may not cover problems caused by your changes.

Questions to ask before you sign

1. What is included in the monthly fee, and what is billed on top?
2. How long is the warranty on faults, and how are faults and changes told apart?
3. Who holds the hosting, domain and third-party accounts: you or the developer?
4. Who gets alerted if the system goes down, and what response time is promised for a fault that stops work?
5. Are backups taken automatically, where are they stored, and has a restore ever been tested?
6. Is the code documented well enough for another developer to take it over? See who owns the code.
7. What happens to the fee and the service if we want to leave?

Ways to keep software maintenance cost down

• Build less in version one. Every feature you do not build is a feature you do not maintain.
• Use standard components where you can. A common payment provider or calendar needs less custom upkeep than one built from scratch.
• Keep the number of connections small. Each outside system is something that can change without warning. Our guide to building or buying a client portal covers this trade-off for one common type of system.
• Batch changes. Collect requests for a month and have them quoted together, instead of sending them one by one.
• Keep the accounts in your name. It makes changing provider an afternoon job instead of a negotiation.

How to budget for the first year

You can plan without a price list by working through the same four parts with your developer and asking for each to be written as a separate line.

1. List every outside service the system uses and its billing basis: monthly, per user, or per message.
2. Ask for the update work as a regular, scheduled item, such as a quarterly check, so it does not wait for a crisis.
3. Set aside a separate allowance for changes. Think about what you are likely to want in the first year: a new report, another user group, one more connection.
4. Keep a small reserve for the unexpected, such as an outside service changing its rules and forcing an update.

Review the bill after six months. Hosting and updates should be steady. If fixes are not falling after the first few months, ask why.

When to rebuild instead of maintain

Sometimes the maintenance bill is a signal. If every small change takes far longer than it should, if the components are no longer supported, or if only one person can touch the code, the system may have become more expensive to keep than to replace. A rebuild is a large decision, so ask for an independent assessment first, and consider replacing it in pieces so the business keeps running throughout.

Early signs maintenance has been neglected

Look for pages that load more slowly each month, errors that “fix themselves” and come back, warning banners from the hosting provider, a developer who cannot say when the system was last updated, and nobody who knows where the backups are. Any of these means the cost you are not paying now is accumulating somewhere.

CentriWeb builds custom software and looks after what it builds, including managed hosting. If you already have a system and are unsure what state it is in, a 30 minute call is a fair place to start. For clinics and similar practices, our page on health and fitness businesses shows how we think about the systems they rely on.