It's 7:40 on a Monday morning. Your crew leads are standing in a driveway trying to log the first job of the day. The app spins. Somebody texts you a screenshot. Somebody else asks if they should just use paper.
Nothing dramatic happened. A service the app relies on changed over the weekend, and nobody was watching.
Custom software isn't a finished object, like a table. It's closer to a vehicle: it runs great for a long time, then needs oil, tires and an occasional look under the hood. Custom software maintenance is the name for that ongoing care, and it's the part of the conversation owners most often skip.
This article answers the question under the question, which is "what if it breaks?" Here's what maintenance covers, who does it, and how to plan for it without any nasty surprises.
Why custom software maintenance exists at all
Software doesn't wear out like a machine. So why does it need looking after?
Because it doesn't live alone. Your app sits on top of a stack of other things: a server, a database, a programming framework, dozens of open source libraries, browsers your team uses, and maybe payment or email services. Every one of those gets updated on its own schedule, by people who've never heard of you.
When something underneath changes and your app doesn't, small cracks appear. A feature quietly stops working. A browser update changes how a button behaves. A library is found to have a security hole and the fix is available, but not installed on your system.
None of that is anyone's fault. An honest proposal includes a plan for it. Our guide to build vs buy software puts maintenance on the cost side where it belongs.
The five jobs that keep software healthy
When people say "maintenance," they usually mean a handful of different jobs. It helps to separate them.
1. Security and dependency updates
Most modern software is assembled from many outside pieces. When one of them has a vulnerability, the fix is a small update. Applying it promptly is the single most valuable thing maintenance does.
The risky part is the gap. An old, unpatched system is exactly what automated attacks look for. Regular updates, tested before they go live, shrink it. The U.S. Cybersecurity and Infrastructure Security Agency puts keeping software updated near the top of its Cyber Essentials guide for small businesses, and for good reason.
2. Backups you've actually tested
A backup is a copy of your data and files, stored somewhere else. It's what turns a catastrophe into an annoying afternoon.
The part owners don't think about is the test. Plenty of businesses discover their backups were empty or unreadable only on the day they needed them. Good maintenance includes checking that a backup can really be restored. We cover the basics in our glossary entry on website backups.
3. Monitoring
Monitoring means something is watching your software around the clock and alerts a person when it misbehaves: the site is down, a page is slow, a certificate is about to expire. Without it, you're the monitoring system, and you find out when a customer or a crew lead complains.
The goal is simple. Somebody who can fix the problem should hear about it before you do. Keeping track of uptime is the usual starting point.
4. Bug fixes
Real use finds things testing didn't, like a date that displays wrong in one time zone or a report that breaks when a client has no invoices yet. A plan should say how bugs get reported and how fast they get looked at.
5. Small improvements
This is the bucket people forget, and it's where software gets better over time. Once your team uses the system daily, they notice things: a field that should be required, a filter that would save a click, a report you wish existed. Small adjustments like these keep the software fitting your business as the business changes.
Decide up front whether some improvement work is included each month or every tweak is a separate quote. Either is fine. Not knowing isn't.
Who do you call when it breaks?
Back to the Monday morning scene. The best time to decide who you call is before it happens.
A good support arrangement answers these questions in writing:
- Who responds? A named team, not a single person's cell phone.
- How do you reach them? One clear channel, such as a support email or ticket form, plus what to do for something urgent.
- How fast do they respond? Ideally with different expectations for "the whole system is down" and "a button looks wrong."
- What's covered? Fixing something that broke versus building something new.
- What happens outside business hours? Be honest about this one. Round-the-clock coverage is a different level of service than business-hours coverage, and it costs differently.
If your builder's answer is "just text me," that's a warning sign. Continuity ties into ownership too: you can only get help from someone else if you own the code, accounts and documentation, which we cover in who owns custom software.
Maintenance you can see versus maintenance you don't
Here's something owners rarely hear. When maintenance is going well, you notice nothing. The updates happen on a quiet evening. The backup test passes. A warning about a slow database gets fixed on Wednesday, and nobody in your office ever knew.
That invisibility is the product, and it's why maintenance is easy to cut: nothing seems to be happening. A good provider sends a short, regular summary:
- What was updated.
- What was backed up and tested.
- Any issues found and fixed.
- Anything coming up that you should know about.
That's how you can tell a plan is working, and how you'll catch it if it isn't.
How to budget for custom software maintenance
We won't hand you a made-up percentage, because the right number depends on your situation. Here's what moves it.
Size and complexity. More screens, more user roles and more business rules mean more to test whenever something changes.
Outside connections. Every service your software talks to, such as payments, email, accounting or mapping, is another thing that can change. Systems with many integrations need more attention than self-contained ones.
Response expectations. Fast responses and after-hours coverage cost more than next-business-day replies.
Hosting and infrastructure. Where the software lives, how much traffic it gets and how it's backed up all affect ongoing cost. For websites and web apps, our hosting and care plans show the kind of coverage that's typical.
How much it changes. A system you tweak monthly needs a different arrangement than one you leave alone for a year.
Then budget in two parts. First, the steady monthly or annual cost for the basics: updates, backups, monitoring and support. Second, a flexible pool for improvements, because you'll want some. Treat the first as a utility bill and the second as an investment you can turn up or down.
Our Price Guide explains how we think about cost drivers for builds, and any good proposal should show maintenance as its own line, not tuck it away or leave it blank.
If a proposal doesn't mention what happens after launch, ask. The silence is the answer.
What a careless approach costs
It's tempting to fix problems only as they come. The first year, nothing seems wrong. Later, things get slow or odd and people work around them. Eventually an update is long overdue, and applying it means jumping several versions at once, which is riskier than doing a little at a time. Then something fails at a bad moment, and the fix has an emergency price.
Skipped maintenance doesn't save money. It moves the bill to a worse day.
Don't overbuy either. A small, stable tool with little sensitive data can run on a lighter plan, and a trustworthy provider will say so.
What we do and what to ask anyone
At Stack Mode we run our own business on StackOS, which we maintain ourselves every day. When something we depend on misbehaves, we feel it the same hour. That's a useful way to learn what maintenance really involves, and it's the experience we bring to client projects.
Whoever you hire, ask them these:
- What does the plan include, in plain terms?
- How do you find out something is wrong?
- When did you last test a restore from backup?
- How quickly will someone respond when I report a problem?
- What happens if I want to move to a different provider?
You don't need to understand every technical answer. You need to hear confident, specific ones.
The short version
Software that runs your business is worth looking after the way you'd look after any other tool you depend on. Plan for updates, backups, monitoring, fixes and a little growth. Know who you call. Put it in writing before you sign, and the Monday morning in the driveway becomes a five-minute text instead of a lost morning.