Maintenance and ongoing support

Everything built decays. Dependencies acquire vulnerabilities, browsers change, vendor APIs are deprecated, certificates expire, models are updated underneath you, and the person who understood the system leaves. Maintenance is the work of absorbing that continuous change so the system keeps doing what it was built to do.

It is the least exciting thing we sell and the one most likely to determine whether the rest of the investment holds its value.

Why this is worth doing properly

The maintenance burden of a modern stack is higher than it was and less visible. A web application depends on hundreds of transitive packages, several of which will publish a security advisory in any given year. Left alone for eighteen months, the upgrade path becomes a project rather than a task.

AI systems introduce a maintenance category that did not previously exist: behavioural drift. Model providers update models, and a system that was measured as accurate six months ago may quietly have changed behaviour with no change on your side. Periodic re-evaluation against a fixed test set is the only way to detect this.

The commercial argument is straightforward. Deferred maintenance does not disappear; it accumulates and is eventually paid at a premium, usually under time pressure and often during an incident. A modest recurring cost is almost always cheaper than the emergency it prevents.

Where this work usually goes wrong

Treating maintenance as optional

Deferring it converts a small recurring cost into a large irregular one, and the large one always arrives at an inconvenient moment. The saving is nominal rather than real.

Monitoring that alerts on everything

Alert fatigue means genuine incidents get missed among the noise. Fewer, more meaningful alerts routed to someone who can act is better monitoring than more of it.

Backups without restore tests

The most common serious gap we find. A backup that has never been restored is an assumption, and organisations discover the difference at the worst possible time.

No documentation for the person after you

Systems that only one person understands are a business risk regardless of how well they work. Runbooks and architecture notes are maintenance deliverables.

Never re-measuring AI accuracy

A system evaluated once was evaluated for one day. Without scheduled re-evaluation, quality degrades invisibly as models change underneath the application.

What this covers

Website maintenance

Updates, dependency patching, uptime monitoring, broken-link checks and content changes.

Software maintenance

Dependency currency, security patching, bug fixes and small enhancements.

Automation monitoring

Workflow execution health, failure alerting and repair when a vendor API changes.

AI-system maintenance

Scheduled re-evaluation against the test set, prompt updates and cost monitoring as models change.

CRM administration

User management, field hygiene, automation upkeep and data quality review.

Cloud infrastructure monitoring

Uptime, latency, cost and certificate expiry, with alerts tuned to matter.

Workflow troubleshooting

Diagnosis and repair when an automation stops behaving as expected.

Security updates

Advisory tracking and patching on a defined schedule, with urgent fixes handled out of cycle.

Backup monitoring

Verification that backups complete, plus scheduled restore tests with recovery time recorded.

Performance optimisation

Ongoing measurement and tuning rather than a one-off pass at launch.

Platform updates

Framework, runtime and vendor platform upgrades handled incrementally instead of accumulating.

Analytics and monthly reporting

A standing report on what changed, what broke, and what we recommend.

Strategy reviews

A periodic conversation about whether what exists still fits what the business is doing.

Technical documentation

Runbooks and architecture notes kept current as the system changes.

Staff training

Sessions for new team members so operating knowledge does not leave with one person.

Retainer-based marketing and technology support

A blended arrangement covering both sides where a business needs the same partner for each.

How the work runs

1. Establish the baseline

   An inventory of what exists, its current patch state, its monitoring coverage and its documentation quality. This defines what is actually being maintained rather than what is assumed to be.

2. Fix the gaps first

   Missing monitoring, unverified backups, outdated dependencies and undocumented systems get addressed before the routine cadence begins. There is little value monitoring a system whose backups do not work.

3. Run a defined cadence

   Weekly checks, monthly patching, quarterly restore tests and reviews. Written down, so you know what you are buying and can tell whether it happened.

4. Respond within an agreed window

   Severity levels and response times specified in the contract, with an escalation path. Goodwill is not a service level.

5. Re-measure AI systems on schedule

   Evaluation sets re-run periodically, with accuracy reported over time so drift is visible rather than inferred from complaints.

6. Report and review

   A monthly report covering what was done, what broke, and what we recommend next — plus what we could not check and why.

What you receive

• Asset inventory and baseline assessment
• Monitoring and alerting coverage
• Scheduled patching and dependency updates
• Backup verification and quarterly restore tests
• AI evaluation re-runs with tracked accuracy
• Agreed response windows by severity
• Monthly report including unchecked items
• Maintained runbooks and documentation

You probably need this if

• Nobody knows when your dependencies were last updated.
• You have never tested a restore.
• An automation broke and nobody noticed for weeks.
• The person who built your system has left.
• Your AI feature seems worse than it was and nobody can prove it.

What we build and work with

Maintenance tooling exists to make the state of a system visible without anyone having to remember to look.

Dependency scanning

Automated advisory tracking on every repository, with severity-based patching cadence.

Uptime and synthetic monitoring

External checks on the flows that matter — the contact form and the checkout, not just the homepage.

Error tracking

Aggregated application errors with alerting on new or spiking issues rather than on every occurrence.

Backup verification and restore drills

Automated verification that backups completed, plus scheduled manual restores with recovery time recorded.

Certificate and domain expiry monitoring

The most preventable outage there is, and one of the most common.

AI evaluation harness

The original test set re-run on a schedule so model drift shows up as a number rather than as complaints.

Ticketing with severity levels

Requests tracked against agreed response windows, so service level is measurable rather than asserted.

What changes once this is in place

Fewer incidents, caught earlier

Monitoring and patching mean most problems are found before a customer finds them.

Restores that have been proven

Scheduled drills with recorded recovery times, replacing an assumption with evidence.

No accumulating upgrade debt

Incremental platform and dependency updates instead of a migration project every three years.

AI quality stays measured

Scheduled re-evaluation, so drift is detected as a number rather than through user complaints.

Knowledge that survives staff changes

Runbooks and documentation maintained as part of the service, not as a one-off at handover.

How this differs by market

The work is the same craft everywhere. What changes is the law, the language and the buying culture — and those change enough to matter.

European Union

NIS2 extends cybersecurity risk-management and incident-reporting duties to a much broader set of sectors, and for in-scope organisations patching cadence and incident response become regulatory obligations rather than good practice. GDPR breach notification runs to a seventy-two hour deadline, which is only achievable with monitoring already in place.

Nordics

Support expectations here are for clear written service levels rather than informal availability, and procurement will usually ask for them explicitly. National CERT reporting obligations apply in several sectors and should be reflected in the incident escalation path.

United States and Canada

Compliance frameworks impose their own cadences — SOC 2 requires evidence of vulnerability management and change control, HIPAA requires audit controls. Breach notification obligations vary by state and province, and the escalation path has to know which apply.

United Arab Emirates

The federal PDPL sets breach notification duties, with DIFC and ADGM operating separate regimes and timelines. Support hours should reflect a Monday to Friday working week, and the Gulf public holiday calendar differs from the European one — which matters for scheduling maintenance windows.

Not legal advice. Regulatory summaries on this site describe how we scope and build, and are current to our latest review. Verify the operative text with qualified counsel in the relevant jurisdiction before relying on it.

How we know it worked

We report uptime, incident count by severity, mean time to detect and mean time to resolve, and response times against the agreed windows. These are read from the monitoring and ticketing systems rather than asserted.

Patch currency is reported as a number — open advisories by severity and their age — because "we keep things updated" is not a claim anyone can check.

For AI systems we report accuracy against the fixed evaluation set over time, so drift appears as a trend line. Every report also lists what we could not check in the period and what access it would need.

Estimates are labelled as estimates. Any figure on this site that describes a range is a planning estimate with its assumptions stated, not a measured client outcome. We do not publish client results without the client's permission and a date.

Related services

Sectors where this is usually the lead engagement

These are the industries where this discipline is typically the first thing a client buys rather than something added later. The link goes to a page written for that sector specifically, with a paragraph on this service and on every other one.

• Healthcare & Clinics — One of the fastest-growing sectors for digital investment, and the one where the constraints on what you may say and where data may sit shape everything.
• SaaS & Software — Buyers who evaluate suppliers professionally, sell to people who do the same, and measure everything — which raises the bar on both sides.
• Fintech & Payments — Startup growth expectations inside a supervised institution, where onboarding conversion and financial crime obligations pull in opposite directions.
• Restaurants & Food Service — Margins measured in single percentage points, delivery platforms taking a third, and allergen data that is a legal obligation rather than a menu detail.
• Marine & Shipping — Assets moving between jurisdictions, crews whose certificates expire, and emissions reporting that has become a financial obligation.

It appears on all thirty sector pages, because every one of them carries a paragraph on all twenty-two services. This list names only the sectors where it tends to lead.

Where we deliver this

This service is delivered across the European Union, the Nordic countries, North America and the United Arab Emirates. The craft does not change; the law, the language and the buying culture do. Consent regimes, invoicing mandates and payment conventions differ enough between markets that a campaign or a system built for one frequently cannot be used unchanged in another.

Each country page sets out what actually differs there and what it means for scope — all 32 countries and 10 cities are listed here. A few of the markets we work in most:

• Germany
• Netherlands
• France
• Sweden
• United States
• United Arab Emirates