[ For software that has to keep working ]
Ongoing maintenance for software that is already live — yours or someone else's. Monitoring, security patching, dependency upgrades, bug fixing and small improvements, on a retainer with defined response times.
Ongoing maintenance for software that is already live — yours or someone else's. Monitoring, security patching, dependency upgrades, bug fixing and small improvements, on a retainer with defined response times.
Tell us what you are running and who supports it nowUptime, error rates, certificate expiry, disk and backups monitored with alerts that reach a person. Most outages are noticed by customers first, and that is the avoidable part.
What counts as critical, how fast we respond, and how you reach us out of hours — agreed up front rather than negotiated during an incident.
Framework, library and runtime updates applied on a schedule. Deferred for three years, an upgrade becomes a rewrite.
We take over software built by someone else. There is an audit first so we both know what we are dealing with.
Monitoring, patching, dependency upgrades, bug fixes and a bank of hours for small changes, on a monthly agreement.
For software built by someone else — a full audit, urgent fixes and a documented handover into ongoing support.
For systems that still work but are hard to change — framework upgrades, test coverage, refactoring and performance work.
Code, infrastructure, dependencies, backups, security posture and documentation. For inherited systems this is where the real risks surface.
Unpatched vulnerabilities, missing backups, expiring certificates and anything that could take the system down this month.
Uptime, errors, performance and infrastructure, with alerting routed to whoever is on call and a defined escalation.
Severity definitions, response and resolution targets, hours of cover, escalation path and monthly hours included.
Patching, dependency updates, backup verification, performance review and the queue of small improvements.
What broke, what was fixed, what was deferred and what is accumulating — with a recommendation on what to do about it.
Software rots whether or not anyone touches it. Dependencies acquire vulnerabilities, certificates expire, disks fill, payment gateways deprecate the API you integrated against, and a phone operating system releases a version that breaks your app. None of that requires a change on your side to happen.
Maintenance is therefore not the same as bug fixing. It is monitoring so problems are noticed before customers notice them, patching on a schedule so upgrades stay small, and keeping a register of what is accumulating so that the eventual bill is a decision rather than an emergency.
A framework two versions behind is a weekend. Five versions behind is a project. The cost of deferring compounds quietly.
A backup nobody has restored is a hypothesis. We test restores on a schedule, because the failures are always discovered at the worst moment.
What counts as critical, who is called and how fast — agreed in calm conditions, not argued about at eleven at night.
Most breaches now arrive through a dependency rather than your own code, which makes routine package updating a security control rather than housekeeping.
Payment gateways, cloud services and mobile platforms retire APIs on shorter notice, so systems left alone break without anyone having changed them.
Routine fixes and updates take less time than they did, which shifts the value of a retainer towards judgement, monitoring and knowing your system.
Yes, and a large share of this work is exactly that. It starts with an audit — code, infrastructure, dependencies, backups and security — because we will not commit to a response time on a system we have not looked at. The audit is quoted separately and is useful to you even if you go elsewhere afterwards.
Let’s talk about your maintenance & support project. No obligation, just a conversation.
Next service
Influencer Marketing