Maintenance and support
Taking over someone else’s system starts with archaeology, not development. Before anything can be safely changed, somebody has to find out what the code actually does — which is rarely identical to what everyone believes it does.
Inheriting a system
The typical handover is a repository, a production server, and a person who has already left. There is no documentation, or there is documentation describing a version from three years ago. Some of the code is dead but nobody knows which. There is a scheduled job whose purpose is unclear and which everybody is afraid to turn off.
So the first two to three weeks are reading, mapping and instrumenting: tracing the request paths that actually get traffic, identifying which code is live and which is vestigial, checking dependency health and licence exposure, and finding out what would happen if the database were lost right now. You get that as a written assessment with the risks ranked, before we propose changing anything.
Quite often the assessment says the system is in better shape than feared and needs three specific things fixed. Sometimes it says the opposite. Either way you are making the next decision with information rather than with anxiety.
The unglamorous work that matters
Dependencies rot. A library that is four years unmaintained is a security exposure and a hiring problem at the same time, and the cost of updating it rises the longer it is left. Keeping dependencies current is boring, continuous, and much cheaper than the emergency version of the same work.
The same applies to platform deadlines: an OS release that deprecates an API, a payment gateway retiring a protocol, a runtime reaching end of life. These have dates attached and can be planned for, and they are the most common cause of an urgent request that did not have to be urgent.
How support actually works
A named engineer who knows your system, rather than a ticket queue and whoever happens to be free. Response times defined by severity and agreed up front, with an escalation path that has a phone number on it.
We keep maintenance and new feature work on separate budgets, because when they share one, maintenance always loses. The consequence is a system that slowly becomes harder to change, and then a rewrite in three years that costs more than the maintenance would have.
What this actually covers
Codebase assessment
A written map of what the system does, what is load-bearing, what is dead, and what the real risks are — ranked.
Takeover and stabilisation
Getting an inherited system into a state where it can be deployed, monitored and changed safely.
Dependency and platform upkeep
Security patches, library updates, runtime upgrades and OS deprecation deadlines handled before they are urgent.
Incident response
Defined severities, agreed response times, a named engineer, and a written post-incident review that produces a fix rather than a blame.
Legacy modernisation
Strangler-pattern migration — replacing a system in place, piece by piece, while it keeps running. Never a big-bang rewrite.
Documentation recovery
Writing down what was never written down, starting with the parts a new engineer needs on day one.
The sequence
Same shape on every engagement, so you always know what week you are in and what happens next.
Archaeology
Two to three weeks reading the code, tracing live request paths, checking dependencies and finding out what is actually load-bearing. Nothing changes during this period.
Stabilise
Monitoring, backups, a repeatable deploy and a tested rollback — before any feature work. You cannot safely change a system you cannot observe or restore.
Pay down the urgent debt
Security exposures and end-of-life deadlines first, ranked by risk. These have dates attached, which makes them plannable rather than dramatic.
Steady state
A named engineer, agreed response times, monthly reporting, and separate budgets for maintenance and new features so the first does not lose to the second.
Handed over, in your accounts
Not a demo and a login. These are the artefacts you keep, and they are what makes leaving us possible.
- A written system assessment with risks ranked by likelihood and cost
- A dependency and licence inventory, with the urgent items separated from the rest
- Monitoring and alerting on a system that probably had none
- A tested restore of the production database
- A runbook covering deploys, rollbacks and the three things that break most often
- A monthly report of what changed, what was patched, and what is coming due
Typically built with
- Node.js
- PHP
- Laravel
- Python
- .NET
- PostgreSQL
- MySQL
- Docker
- Sentry
The selection principle is deliberately dull: largest hiring pool, longest support window. See why we choose these.
Maintenance & Support, answered
The things people ask on the first call, written down so you do not have to.
Can you take over a project from another agency?
Yes, and it is a normal way for us to start. The first two to three weeks are assessment rather than development — reading the code, mapping what actually runs, checking dependency and licence health, and testing whether the backups restore. You get a written assessment with risks ranked before we propose any work. We would rather tell you the system is fine and needs three fixes than sell you a rebuild you do not need.
What does a maintenance retainer include?
Security patching, dependency and runtime updates, platform deprecation deadlines, monitoring and incident response with agreed response times by severity, and a monthly written report of what changed and what is coming due. New features are quoted separately and deliberately so — when maintenance and features share one budget, maintenance always loses, and the bill for that arrives as an expensive rewrite two or three years later.
Our system is old. Should we rewrite it?
Usually not all at once. Big-bang rewrites have a poor record: they take longer than planned, the old system still needs maintaining throughout, and the new one has to reach parity with a system whose behaviour was never fully documented before it can replace it. The pattern that works is strangler migration — put a routing layer in front, replace one area at a time, and let the old system shrink. It is less satisfying and much more likely to actually finish.
How fast do you respond when something breaks?
By agreed severity, written into the engagement rather than implied. A production outage gets a response within an hour during working hours and has an out-of-hours escalation path with a phone number on it. A cosmetic issue gets picked up in the next cycle. What we will not do is promise a one-hour response to everything, because a promise like that is either untrue or extremely expensive, and both are worse than an honest tier.
What usually comes with this
- BuildCustom Software DevelopmentCustom platforms, marketplaces and SaaS. We write the parts that are specific to your business and buy the parts that aren’t.Read more
- RunCloud & DevOpsDeploys that are boring on purpose. Infrastructure as code, real environments, and a bill you can read line by line.Read more
- RunQA & Software TestingAutomated regression suites where they pay for themselves, and exploratory testing where they don’t. We tell you which is which.Read more
- GrowStaff AugmentationEngineers who join your standup, your repo and your review process. Billed monthly, replaceable, and yours to direct.Read more
Thinking about maintenance & support?
Start with a call rather than a brief. Thirty minutes, no deck, and an honest answer about whether we are the right people for it.