Understanding Maintenance and Support

The build finishes. The software does not. Running something is a different job from making it, with different costs and a different kind of attention, and it is the part people plan for last. Here is what upkeep actually covers, what is fair to pay for, and what to agree before the day you need it.

What maintenance actually covers

It is not one thing, and the parts are not equally urgent.

• Security updates. Your software sits on top of other people's code: the language, the framework, the libraries that handle logins and payments and file uploads. Those pieces get security fixes, and applying them is most of routine maintenance. It is the least visible part and the one you least want to skip.
• The ground moving. Browsers change. Phones update. The services you connect to change how they work and retire the old way of doing it. None of that is caused by your software, and all of it lands on your software.
• Hosting and backups. Something has to run it, and somebody has to check that the backups restore. A backup nobody has restored is a hope.
• Fixes. Things that were supposed to work and do not.
• Changes. Your business moving. A new price rule, an extra approval step, a report you did not know you wanted until you had the first one.

A fix and a change are not the same thing

This is the distinction most worth settling early, because it decides who pays. A fix restores what you already paid for. A change is new work you are asking for.

The line is easy to draw on paper and less obvious in real cases, which is why it is worth agreeing while everybody is relaxed about it. What helps is having the written scope from the build to point at: if the software is not doing what that document says, it is a fix. If the document did not ask for it, it is a change, and it gets estimated and approved like any other work.

Hosting is its own bill, and it should be yours

Somebody has to provide the servers. That is a separate cost from anyone's maintenance fee, and the account should be in your name with your card on it, for the same reason the code should be yours.

What it costs depends on what the software does and how much of it there is, so nobody can quote it from a description. Ask for an estimate based on your actual project, and ask specifically what would make it go up. Then you will recognize the answer when it does.

Support is a response, not a product

The word covers very different arrangements, so pin down what yours means before you rely on it. How do you report a problem? Who sees it? What happens next, and what does it cost?

Ask what response time is promised and what happens if it is not met. Some providers publish formal guarantees. Many do not. Either can be a reasonable deal. Not knowing which one you have is not, because you will find out on the morning it matters.

Ours is plain, and worth saying rather than leaving you to assume: we do not publish a service level agreement and we are not available around the clock. You should know that going in, and you should ask the same question of anyone else you talk to.

What it costs

Ours is optional and starts at $1,000 a month. The number matters less than the word optional, and the word optional is only true because of what you own: the repository and the deployment documentation are yours on final payment, so keeping us is a decision you make on the merits rather than one made for you.

The real choice is between paying monthly and paying per piece of work. Monthly means somebody already knows your software when you call, and the security updates happen whether or not you remember to ask for them. Per piece of work costs nothing in a quiet month, and starts with a reminder of how it all fits together. Neither is wrong. Pick one on purpose instead of drifting into the second one by default.

You are not required to keep the people who built it

When you own the code, maintenance is a job you can give to whoever you want: the original team, your own developer, or somebody new. What makes that real rather than theoretical is ordinary and checkable. The repository is yours. The documentation explains how to deploy it. The accounts are in your name. The technology is something a working developer will recognize.

Handing it over will still cost some time, because somebody has to learn it. What matters is the difference between a handover that is ordinary work and one that is not possible at all.

Agree these before you need them

• What counts as a fix and what counts as a change?
• How do I report a problem, and what happens after I do?
• What is included in the monthly amount, and what is billed on top?
• Who has access to what, and whose accounts is everything in?
• What notice ends the arrangement, and what do I have when it ends?

Those are the same shape as the questions in part eight, because they come from the same place: write it down while nothing is wrong.

What skipping it looks like

Nothing happens for a while. That is exactly what makes it easy to skip. Then a library with a known security hole is still sitting in the thing your customers log into. A service you connect to changes, and a step stops working quietly, so you find out from a customer. Small changes you did not make queue up until the software no longer matches how you actually work, and somebody starts keeping a spreadsheet on the side.

Which is where you came in. That spreadsheet is the reason you built the software in the first place.

Budget it as a line, not a surprise

Software needs upkeep the way a truck needs servicing. You do not decide each month whether to believe in oil changes. Put a number in the budget before the build starts, so the cost of running it is part of the decision rather than something you discover afterward.