The system keeps working after the project ends.
Post-launch maintenance, monitoring and support for the software you run: named engineers who know the codebase, agreed response times, security patches on schedule, and a regular report of what changed and why.
- Assessment
- Wiring
- Steady state
- Review
You are not buying hours.
Software does not stop needing engineers when the project closes. Dependencies age, certificates expire, a vendor changes an API, a user finds the edge case nobody tested, and the person who built it has moved on. The cost of that is paid at the worst moment: an outage on a Monday morning with nobody who knows the system.
Maintenance is how we run our own platforms, and we offer the same discipline for the systems you run — whether we built them or someone else did. A named team learns the codebase, monitoring is wired so we can see problems before users report them, patches and upgrades happen on a schedule rather than after an incident, and at a rhythm agreed with you, you receive a written account of what changed, what broke, and what we recommend next.
You are buying the assurance that someone competent is responsible for the system.
Four things a maintained system gets that an abandoned one does not.
Scope is agreed per system and written into the service description; the levels below are the usual shape.
Monitoring and incident response
Uptime, errors, latency and the business checks that matter — an order that did not complete, a job that did not run — watched by people, with agreed response times by severity and a runbook for every alert.
Patching and upgrades
Security patches on a schedule, dependency and framework upgrades planned and tested before they are due, certificates and credentials rotated before they expire.
Fixes and small enhancements
Bugs found by users or by monitoring, fixed by engineers who know the codebase, with tests. Small improvements delivered from a prioritised backlog you control — see performance optimisation for the larger ones.
Support for your users
Second- and third-line support behind your own helpdesk: your first line handles the questions, we handle the ones that need an engineer, with a ticket trail and response times you can report on.
How the work runs, day to day.
Named engineers, written scope, regular reports.
Each system has a named lead and a backup who have both worked in the codebase. The service description states what is monitored, what is patched, what response times apply to which severity and what is out of scope. The regular report lists incidents, changes, upgrades done and due, and the risks we see coming.
- Severity-based response times, in writing, measured and reported
- A backlog you prioritise; we estimate and deliver inside the agreed allowance
- Regular review of the risks, at a rhythm agreed with you: ageing dependencies, capacity, security findings
- 01Alert
- 02Triage
- 03Fix
- 04Verify
- 05Report
Every incident ends in a written cause and, where needed, a change
How a system comes under maintenance.
Assessment
Code, infrastructure, dependencies, monitoring and documentation reviewed. A risk list and the service description come out of it.
Wiring
Monitoring, alert routing, access, runbooks and the first round of overdue patches. The named team completes its handover from whoever built the system.
Steady state
Agreed response times in force, the agreed reporting rhythm running, the backlog in your hands.
Review
Risks, capacity and upgrade plans reviewed with you; scope adjusted when the system or the business changes.
What you keep.
- A written service description with scope, severities and response times
- Monitoring and alerting wired to a team that answers
- Patches and upgrades done on schedule, with a log
- A regular report of incidents, changes and risks
- Runbooks and documentation kept current
When this is the right call.
Choose this when a system your business depends on has no team behind it, when the people who built it have moved on, or when your own engineers are spending their time on firefighting instead of building.
Look elsewhere if the system is about to be replaced — maintenance money is better spent on the replacement — or if what you really need is a product team: see dedicated teams.
Frequently asked questions
Services that pair with this.
Which system keeps you up at night?
Tell us what runs on it and who looks after it today. An engineer reads it and replies in writing with an assessment of what coverage it needs.