Support

Maintenance

Scheduled work that stops small problems becoming outages

How this is usually engaged

A rolling monthly agreement with an agreed cycle and an allowance of hours, cancellable with notice on either side. Response times, availability expectations and escalation routes are set per engagement and written into the support agreement. We can maintain systems we did not build, following a familiarisation period to read the code and document what we find.

Start a project brief

Practice: Support & Maintenance
Sectors: 4 served
Process: 5 stages
Standard: Built and tested to WCAG 2.2 AA

Ongoing patching, dependency updates, certificate and backup verification, and performance monitoring, carried out on an agreed cadence with a record of what changed.

01What this solves

The problem this addresses

Most production incidents are not novel. They are an expired certificate, a disk filling, a dependency with a published vulnerability that has been available to patch for months, or a backup that has never been restored and turns out not to work. These are all foreseeable and all cheap to prevent, but they need someone whose job it is to look — and after launch that responsibility usually belongs to nobody in particular until the day it becomes urgent.

02Capabilities

What is included

Dependency and platform updates

Language runtimes, frameworks and libraries updated on a cadence, applied in staging and verified by the test suite before production. Small regular updates rather than a frightening annual one.

Security patching

Monitoring for published vulnerabilities in what you actually run, graded by severity and real exposure, with urgent patches applied outside the normal cycle when warranted.

Backup and restore verification

Backups checked for completion and restored to a separate environment on a routine, because an untested backup is a hypothesis. The restore is timed, so recovery expectations are based on evidence.

Certificate and renewal tracking

TLS certificates, domains, API credentials and third-party subscriptions tracked with advance warning, so nothing expires on a bank holiday weekend.

Performance and capacity review

Response times, error rates, database growth and infrastructure cost reviewed against the previous period, with trends flagged before they become incidents.

Documentation upkeep

The runbook, architecture notes and deployment instructions updated as the system changes, so the documentation stays worth reading.

03Use cases

Where this work usually starts

A system live with no owner

The build finished, the team moved on, and nobody is currently responsible for updates. It works today, which is why the risk is invisible.

Professional Services

A store that cannot afford quiet degradation

Checkout depends on several third-party integrations that change without notice. Regular verification catches breakage before customers do.

E-commerce

Meeting a customer's supplier requirements

A client or insurer requires evidence that systems are patched and backed up. The maintenance record provides it as a by-product of doing the work.

Finance

04Approach

How we approach it

We run a scheduled cycle against your system: dependency and platform updates applied in a staging environment and verified by the automated test suite before production, certificate and domain renewals tracked ahead of expiry, backups restored on a routine to prove they work, and performance and error rates reviewed against the previous period. Each cycle produces a short written record of what was changed and what was noticed. Anything urgent is raised immediately rather than held for the next report.

05Process

How the work runs

The order matters more than the ceremony. Stages overlap in practice, but none of them is skipped.

01
Familiarisation
For systems we did not build: reading the code, mapping the infrastructure, testing the deployment path and writing down what we find. Charged once, at the start.
02
Baseline and access
Monitoring and alerting confirmed or added, least-privilege access issued to named people, and the escalation route agreed with your side.
03
Scheduled cycle
Updates applied in staging, verified, then promoted to production in an agreed window with a rollback path prepared before starting.
04
Verification
Restores tested, certificates checked, performance and cost compared against the previous period.
05
Report and review
A written record each cycle, and a periodic review conversation about anything the trend data suggests is worth addressing properly.

06Deliverables

What you receive

Everything below is handed over as part of the engagement. If you take the work elsewhere afterwards, the next team has what it needs.

Maintenance scheduleWhat is checked, how often, and in which environment.
Cycle reportWhat was updated, what was noticed and what needs a decision from you.
Restore test evidenceDate, scope and elapsed time of each verified restore.
Dependency and vulnerability register
Updated runbook and architecture notes

07Technologies

What we use on this work

These entries are drawn from our managed technology directory, which records why each one is in our stack and what we reach for it for. Nothing outside this list is claimed for this service.

Languages & Runtimes

TypeScript
Node.js

Data & Storage

PostgreSQL

Cloud Platforms

Amazon Web Services

DevOps & Operations

Docker
GitHub Actions
Grafana
Sentry

The full technology directory

Highlighted entries are used routinely on delivery work

08Security

How this is kept secure

Security patching is treated as the highest-priority routine work, with the response to a published vulnerability graded by severity and exposure rather than applied uniformly. Our access to your environments is least-privilege, individually attributed and reviewed at agreed intervals, and every change is traceable to a person and a ticket. Backup restores are tested to a separate environment so a restore never overwrites live data.

Our full security and quality approach

09Questions

Asked before we start

Will you maintain a system you did not build?

Usually, yes, after a familiarisation period to read the code, map the infrastructure and test the deployment path. Where we find the system cannot be deployed safely or has no test coverage at all, we will say what needs to change before maintenance is meaningful — and give you the option to have that work done first or to walk away.

What response time will we get?

That is agreed for your engagement and written into the support agreement, because the right answer depends on what the system does and what an outage costs you. A booking system taking money overnight and an internal reporting tool warrant different commitments, and different prices. We would rather agree something we will meet than publish a number that flatters us.

Does maintenance include new features?

No. Maintenance keeps what exists working and current. New functionality is scoped and quoted separately, which keeps both honest — otherwise the update cycle quietly turns into unplanned development and the patching stops happening.

Is this worth paying for on a small site?

Often not. A brochure site on a managed platform with automatic updates and few integrations may need very little beyond occasional attention, and a maintenance agreement would be poor value. It becomes worthwhile when the system holds data you would miss, takes payments, or has integrations that break when someone else changes an API.

START HERE

Talk to us about Maintenance

The project brief takes about five minutes and gives us enough to have a useful first conversation about Maintenance rather than a generic one. If you would rather just ask a question, the short form is there for that.

Start a project Send a short message

We read every enquiry ourselves. If we are not the right fit, we will say so and tell you what to look for instead.