Shipping It Was the Cheap Part
An application does not stay still after launch. Dependencies get vulnerabilities, browsers and app stores change the rules, load patterns shift, and the certificate nobody wrote down expires on a Sunday. Software maintenance is what keeps a working system working, monitoring that tells us before your users do, security patching on a schedule, corrective fixes with a committed response time, and a monthly budget for the small improvements that never make it onto a project plan.
What Software Maintenance Includes
- Corrective, fixing What Broke: Bug fixing with a response time written into the contract, prioritized by real impact rather than by who shouted loudest. Each incident ends with a short root cause note, because a fix that does not explain itself tends to come back with a different symptom.
- Preventive, stopping the Next Outage: Uptime and error-rate monitoring, log review, database and backup health checks, certificate and domain expiry tracking, and disk and quota alerts. Most of the incidents we prevent are the boring ones that would have taken a site down at the worst possible moment.
- Security Patching on a Schedule: Dependency and runtime updates applied on a regular cadence and tested before they reach production, plus out-of-band patching when a genuinely critical vulnerability lands. Postponed updates are the most common way a maintained system quietly becomes a legacy one.
- Evolutionary, the Small Improvements: A monthly allowance of hours for the changes that are too small to become a project and too useful to keep ignoring, a new field, an extra report, a form that confuses everybody, a slow screen. Unused hours are visible in the monthly report, never invented to fill the invoice.
- Performance and Cost Review: We watch response times, slow queries and Core Web Vitals, and we review your hosting bill alongside them. Performance work and cost work are usually the same work. The query that makes a page slow is often the one paying for an oversized server.
- Takeover of Systems We Did Not Build: Most of what we maintain was written by somebody else. We start with a short handover audit to learn the system and find the immediate risks, then take it on. No obligation to rebuild it with us. Maintenance and redevelopment are separate decisions.
How We Take Over a System
- Handover Audit: Before quoting we spend a few days on the code, the infrastructure and the incident history to learn what we are agreeing to maintain. You get the findings whether or not you sign, including anything urgent we found on the way.
- Access, Inventory and Bus Factor: We inventory every account, domain, certificate, repository and third-party service the system depends on, and check who actually controls each one. This step regularly turns up a critical service registered to a personal email of somebody who left.
- Monitoring and Baseline: We instrument uptime, errors and performance before changing anything, so improvements can be proven rather than claimed. The baseline is also what tells us whether a complaint about slowness is new or has been true for two years.
- Stabilization Sprint: The first month targets the immediate risks the audit found, unpatched vulnerabilities, backups that were never restored to check, and the failure everyone has learned to work around. After this the contract settles into its normal rhythm.
- Monthly Cycle: Patching, preventive checks, incident handling and the evolutionary hours, closed off with a report in plain language, what happened, what we changed, what we recommend next, and how many hours you used. No dashboards you have to interpret alone.
- Quarterly Review: Every three months we step back, is the debt growing or shrinking, is the plan still the right size, is there anything worth turning into a proper project. If the honest answer is that you need less maintenance than you are buying, we will say so.
The Four Kinds of Maintenance
Maintenance contracts go wrong when nobody agreed what the word covers. These are the four categories we quote against, so you know in advance which bucket a request falls into and whether it is already paid for.
- Corrective: Something works differently than it should: Bugs, failed integrations, errors under specific conditions. Covered by the contract with a committed response time, graded by whether the business can keep operating while it is open.
- Critical incidents: 4h response
- Root cause note per incident
- Included in every plan
- Preventive: Nothing is broken yet: The work that stops incidents from happening, monitoring, backup verification, expiry tracking, capacity review. It is the part clients are tempted to cut, and the part that decides how often you need the corrective part.
- Uptime and error-rate alerting
- Backup restore tested, not assumed
- Monthly health review
- Adaptive: The world around the app changed: Nothing in your code changed, but a dependency, an operating system, a browser, an app store policy or a tax rule did. Ignoring this category is what turns a healthy application into one that cannot be updated at all.
- Scheduled dependency updates
- Out-of-band critical patching
- iOS and Android SDK compliance
- Evolutionary: It works, and it should do more: New fields, new reports, usability fixes, small features. Billed against a monthly hour allowance so these never have to wait for a formal project, with anything larger quoted separately before we start it.
- Monthly hour allowance
- Unused hours reported, not invented
- Larger work quoted before starting
Platforms We Maintain
We maintain applications on the stacks we build with and on plenty we would not have chosen. What matters for a maintenance contract is that the system is understandable and deployable, not that it uses our preferred tools.
Frequently Asked Questions
Will you maintain an application another agency built?
Yes, that is most of this work. We need read access to the code, the infrastructure and whatever documentation exists, and we run a short handover audit first so we are not quoting blind. We do not require you to rebuild anything with us as a condition, and we will tell you plainly if a system is in a state where maintenance alone is not a responsible answer.
How much does a maintenance contract cost?
It depends on the size of the system, how critical it is and how many evolutionary hours you want included. A single web or mobile application and a business-critical estate are not comparable, so the contract is quoted after the handover audit. The audit itself is quoted separately and is a one-off.
What counts as an emergency, and what happens at 3am?
An emergency is the application being down or a critical business flow such as payments or login failing, and that is what the committed response time applies to. Automated monitoring alerts us at any hour, and for business-critical systems we agree an out-of-hours arrangement in the contract rather than leaving it to goodwill. A slow page or a cosmetic bug is handled in the normal cycle.
What is the difference between this and a technical debt audit?
Maintenance keeps a working system working, month after month. A technical debt audit is a one-off diagnosis of why the system has become expensive to change, with a plan to fix the causes. They fit together, clients often start with the audit and then move onto a maintenance contract, or notice during maintenance that a specific area deserves a proper audit.
Are unused evolutionary hours lost at the end of the month?
The monthly report always shows how many you used, and we agree the carry-over rule in the contract before we start rather than leaving it ambiguous. What we will not do is invent work to consume the allowance, a quiet month is a good outcome, and pretending otherwise is how maintenance contracts lose trust.
Can we cancel? Are we locked in?
Contracts are monthly with a notice period agreed up front, and everything we set up stays in your accounts, repositories, infrastructure, monitoring and documentation. If you leave, we hand over an up-to-date inventory of accesses and dependencies so the next team starts with what we knew rather than from scratch.