For applications already in production, built by us or inherited from somebody else. Dependency updates, security fixes, monitoring and a person on the other end of the phone.
The pattern is familiar. A system was built a few years ago, it works, people use it daily. The firm that made it no longer works with you, the developer who knew it has left, and the documentation, if it ever existed, is out of date.
Meanwhile the dependencies accumulate published vulnerabilities, the certificates approach expiry, the systems it connects to change their interfaces, and the language version it runs on approaches the end of support.
None of this is visible until the day something gives way. And on that day, the question "who do we call" has no answer, which turns a problem of a few hours into one of a few days.
We do not take a system we do not understand into a subscription. The assessment is quoted separately and you get the result whether or not we continue together.
| Area | What we check | Why it matters |
|---|---|---|
| Dependencies | Versions, published vulnerabilities, abandoned libraries | The most frequent source of risk, and the cheapest to treat if done in time |
| Platform version | How much support the language or framework still has | A system on an out of support version receives no security fixes at all |
| Infrastructure | Where it runs, how it is deployed, who has access | If deployment exists only in somebody's head, the system is effectively unrecoverable |
| Backup | Does it exist, is it automatic, has it ever been restored? | On takeovers we frequently find backups that have run for years and were never tested |
| Secrets and keys | Where passwords and keys live, who knows them, when they expire | Expired certificates are among the most banal and most irritating outages |
| Automated tests | Do they exist, do they run, do they cover what matters? | Without them, any change becomes a risk and the team starts avoiding the system |
| Logs and monitoring | Is anything recorded, does anybody look at it? | Without monitoring, you find out from users. With it, you find out first |
| Personal data | What is collected, how long it is kept, who has access | An old system often accumulates data it should no longer hold |
Sometimes the assessment shows that maintenance costs more than rebuilding: a platform out of support with no upgrade path, abandoned dependencies with no replacement, code with no structure that any change destabilises. We tell you that directly, with the figures for both options. A maintenance subscription for a system that should be rewritten is an elegant way of deferring the problem at your expense.
Small and frequent updates, not large and rare jumps. A library left untouched for two years can no longer be updated incrementally: you reach a huge jump meaning weeks of work and a risk of regression across the whole system.
We continuously monitor published vulnerabilities for every component. Critical ones are applied immediately, the rest enter the monthly cycle, tested beforehand.
Availability, errors, response time, disk space, stuck queues, scheduled tasks that have stopped running. With thresholds agreed together, so alerts mean something and are not ignored after two weeks.
Response deadlines are written into the contract, differentiated by severity. A system that is down does not have the same deadline as a display error, and pretending otherwise would be dishonest.
Automatic copies, held on infrastructure separate from the system, and actually restored in an isolated environment at regular intervals.
An untested backup is an assumption. On takeovers we frequently find copies that have run for years and were never restored, and some of which could not have been.
How it is deployed, how a release is made, how to roll back, what to do for each type of incident. Updated alongside the system rather than written once and left to age.
It is also your insurance against us: if tomorrow you work with somebody else, the handover takes days rather than months.
Included in the subscription: dependency and platform updates, security fixes, monitoring and alerting, incident response, backup and its testing, small behavioural corrections, adaptations required by changes in the external systems it connects to, monthly reporting.
Quoted separately: new features, major process changes, infrastructure migrations, component rewrites. All estimated beforehand, in writing, at a firm price. You do not get a surprise invoice for work you have not approved.
For WordPress sites we have a separate service, with a different kind of work and a different price. See WordPress maintenance.
Yes, it is in fact the most frequent case. We start with a separately quoted assessment in which we read the code, the infrastructure and the dependencies, then give you an honest report on what state it is in and what it would cost to bring it up to date. If the assessment shows a rewrite is cheaper than maintenance, we tell you that.
That is the usual situation with inherited applications. We build it as we go, starting with what is critical: how it is deployed, how a release is made, what happens during an incident. We do not document everything at once, because that would be money spent on parts of the system nobody touches.
It depends on severity, and the thresholds are agreed together and written into the contract. A system that is down does not have the same deadline as a display error. What we do not do is promise identical deadlines for everything, because that would mean either inflating the urgent ones or being unable to meet them.
Because vulnerabilities are published daily for libraries everybody uses, and automated scanners look for exactly the affected versions. On top of that, a dependency left untouched for two years can no longer be updated incrementally: you reach a huge jump, meaning weeks of work and considerable risk. Little and often is far cheaper than a lot and rarely.
It is a different service. Here we are talking about custom applications, with code written specifically for you, their own dependencies and dedicated infrastructure. For WordPress sites we have a separate subscription, with a different kind of work and a different price.
We run an assessment and tell you honestly what state it is in, what risks you carry now and what it would cost to bring it up to date. Including if the answer is that it is not worth maintaining.