“Maintenance” is one of the vaguest words in software. Ask three vendors what their monthly plan covers and you’ll get three different answers, and at least one of them means “we’ll answer the phone.” That vagueness works in the vendor’s favor, not yours.
Here is what actually sits behind a real software maintenance plan, why the boring parts are the expensive ones to skip, and the specific questions to ask before you sign anything.
The part everyone forgets: software decays even when nobody touches it
A finished website or application is not a finished object. It sits on top of a stack of other people’s software: a runtime, a framework, a database, a hosting platform, a payment processor, a browser. All of those change underneath you whether or not you ship a single new feature.
A dependency gets a security patch. A browser deprecates an API your site relies on. Your payment provider retires an old integration version. None of that is your fault, none of it appears on your roadmap, and all of it eventually breaks something. This is the actual reason maintenance exists, and it is why “we don’t need changes right now” is not the same as “we don’t need maintenance.”
What a real plan covers
A maintenance plan worth paying for covers five distinct things. If a proposal is missing one of them, that is a question to ask, not necessarily a dealbreaker.
Security updates and dependency patching. Someone is watching for vulnerabilities in the libraries your software depends on and applying patches before they become incidents. This is the single highest-value line item and the one most often left implicit.
Uptime monitoring and incident response. Something checks that the site is up, and a human is responsible when it is not. The important detail here is not the monitoring, which is cheap, but the response commitment: who gets paged, how fast, and on whose schedule.
Backups that have actually been tested. Backups are worthless until someone has restored from them. Ask when the last restore test happened. A vendor who cannot answer that has backups in the same sense that an unopened parachute is a parachute. We wrote more about this in our backup and disaster recovery guide.
Small changes and content updates. Most plans include some amount of ongoing change: copy edits, a new page, a form field, a price update. The question is how that allowance is measured, which we get to below.
Hosting and infrastructure management. Certificates renew, storage fills up, platform versions reach end of life. Someone has to own that, and if the plan does not say who, the answer is usually you.
The three questions that reveal what you’re actually buying
How are included changes measured? Hours, tickets, or scope? Hours are honest but can feel adversarial. Ticket counts are simple but reward padding. Scope-based plans work when both sides trust each other and fail loudly when they don’t. There is no universally right answer, but there is a wrong one: no definition at all.
What is explicitly excluded? A good plan says so plainly. New feature development, redesigns, third-party subscription costs, and emergency work outside business hours are the usual exclusions, and there is nothing wrong with any of them being excluded. There is a lot wrong with finding out during an outage.
What happens if you leave? Where does the code live, who holds the credentials, and what is the offboarding process? This overlaps heavily with who owns your website, and it is the question vendors like least, which is exactly why it is worth asking.
Why we price maintenance as a plan rather than by the hour
We used to sell projects and then quote hourly for changes afterward. It created a bad incentive on both sides. Clients hesitated to ask for small fixes because every request had a meter running, so small problems accumulated into large ones. We ended up doing expensive emergency work that a ten-minute fix months earlier would have prevented.
A monthly plan removes the friction from asking. That is most of the value: the software stays maintained because keeping it maintained does not require a purchase decision every time. We explained the full reasoning behind that shift in why we stopped selling one-time websites.
What maintenance is not
Maintenance is not a roadmap. A plan that keeps your software healthy and handles small changes is not the same as a plan that builds you new capability, and conflating the two is how both sides end up disappointed. If you have a significant new feature in mind, that is project work sitting alongside the plan, not something to quietly absorb into it.
It is also not insurance against every possible event. A plan that covers patching and monitoring will not cover rebuilding after a platform you depend on shuts down entirely. Knowing where the boundary sits is more useful than pretending there isn’t one.
How to evaluate a proposal in five minutes
Read the plan and ask yourself: if the site went down at 9pm on a Saturday, does this document tell me what happens next? If a critical security patch drops on a Tuesday, does it tell me who applies it and when? If I want to change a price on the pricing page, does it tell me whether that is included?
Three concrete questions, three concrete answers. A plan that answers them is a real plan. A plan that answers them with adjectives is a retainer with a nicer name. If you want a second opinion on one you’ve been handed, send it over and we’ll tell you what it does and doesn’t cover.
Not sure what your current plan covers?
Send us the proposal or the invoice. We’ll tell you in plain language what it includes, what it doesn’t, and whether the price is fair. No pitch attached.
Get a Free Consultation