1. Home
  2. How we work
  3. Ongoing support

Ongoing support

After launch, the systemkeeps getting better.

Ongoing support keeps the system healthy, improves it on evidence, and reports in writing what changed and what it produced.

You can stop at any point. The system is yours and keeps running.

Book a discovery call Start with an audit
Support/HealthSample data
  • Uptime and errors watched
  • Updates tested before live
  • Restore performed and recorded
  • CRM connection slow, owner alerted

Shortlist for your decision

Waiting

Shorten the quote form. Evidence: the same question arrives by phone.

Illustration with sample data: a support health view with uptime watched, updates tested, a restore performed, and one slow CRM connection flagged with its owner alerted, plus a shortlisted improvement waiting for the client's decision.

A system with no ownerdoes not stay still.

Without support

It drifts.

  1. The team that built it moves on.no owner
  2. A dependency falls behind.unpatched
  3. A form quietly stops sending.unnoticed
  4. Nobody reads the analytics.unread
With support

It improves, on evidence.

  1. Every alert points at a person.Monitoring
  2. Updates go through a test environment.Patching
  3. You choose what changes next.Your decision
  4. What changed and what it produced, in writing.Report
Illustration: without support, the team moves on, dependencies fall behind, a form stops sending, and nobody reads the analytics. With support, alerts point at a person, updates are tested, you choose what changes next, and a written report says what changed.

What ongoing supportcovers.

01

Keep it healthy

Monitoring, alerts to a named person, updates and patching through a test environment, and backups with a restore actually performed.

02

Make it better on evidence

A shortlist drawn from analytics, support, and your team, then a few changes done properly, one at a time and reversible.

03

Tell you what happened

A regular written report, a named person accountable for the work, and a response commitment agreed in writing.

The full capability list
Ongoing support, the capability table
Capability What it does What it changes
Keep it healthyThe part that runs whether or not anything else does
Monitoring Uptime, errors, performance, integration failures and security alerts, watched continuously. You hear about a problem from us rather than from a customer.
Alerts to a person Every alert routed to a named human being with a path to follow, rather than to a shared inbox. Something being down has an owner from the first minute.
Updates and patching Dependencies, platform and security updates on a schedule, through a test environment before anything touches live. The system does not age into a version nobody can safely update.
Backups and a tested recovery Backups taken, and a restore actually performed rather than configured and assumed. The recovery plan is a thing that has happened rather than a thing that is written down.
Agent monitoring Where an agentic system is running: drift, quality drops and the shape of what is being held at the gate. A system that quietly got worse is noticed by a measurement rather than by a complaint.
Make it better on evidenceA few changes done properly
The shortlist What to change next, drawn from analytics, from support, and from what your team is actually asking for. The roadmap is evidence rather than whoever spoke last.
Improvement work A small number of changes, done properly, one at a time and reversible, rather than a long list done partly. Each change can be judged on its own, because it went out on its own.
Conversion work Headlines, pages and paths tested against real numbers rather than against opinions about them. The argument about the homepage ends with a measurement.
Content production Publishing what the system needs to keep producing, per language, on a schedule you set. The publishing commitment made at launch is kept after it.
Search and visibility maintenance Where that is part of the arrangement: structured data, crawler access and fact consistency kept current as pages change. A rebuild or a content change does not quietly undo work already paid for.
Tell you what happenedIn writing, with a date on it
The written report What happened, what changed, what it produced, what did not work, and what we recommend next. There is a document to take to a board rather than a screen to interpret.
A named person Someone accountable for the work, who was involved in building your system rather than introduced afterwards. The relationship survives a staff change on either side.
A response commitment What happens when something is wrong, how quickly, and by which route, agreed in writing rather than implied. Nobody is guessing about the seriousness of a problem at seven in the morning.
The roadmap review The roadmap read against the business as it is now, rather than against the backlog as it was. Work that stopped being worth doing gets removed rather than done.
The record of the work What changed, when, by whom and why, kept as a document so the next team starts informed. Stopping costs you nothing, which is what makes the arrangement worth continuing.

Scroll the table sideways to read it.

The report sayswhat did not work, too.

your-company/support/report 5 entries, 1 reversed

What changed, and what it did

Written for a person. One page. A period where nothing moved is still a report.

  • Patching, on scheduleThe track underneath

    Dependency and platform updates through the test environment, on schedule. Nothing here was chosen and nothing here is optional.

    Done
  • The quote form, shortenedChosen from support requests

    Four fields removed after the same question arrived by phone repeatedly. More forms are being completed and the replies now take one exchange rather than two.

    Kept
  • A restore, performed and timedScheduled obligation

    A full restore into a clean environment, timed end to end, with the result recorded. This is the entry that makes the backup line mean something.

    Done
  • The new homepage headlineChosen from the shortlist

    Tested against the previous one. It did not do what we said it would, so it is back. The reason it was proposed is in the report along with what we got wrong.

    Reversed
  • Recommended nextFor your decision

    Two candidates with the evidence behind each, and one thing we recommend removing from the backlog because the business no longer needs it.

    Waiting
One of the five entries is a change that did not work and was reversed, and it is in the report rather than in nobody's memory. A report with nothing negative in it is a report that has stopped being read, usually by the person writing it first.

How itstarts.

It starts with a handover: documentation, monitoring configured, a restore performed, and the response commitment written down for each severity. What is covered, how it is reported, and its price and timing are agreed in writing before it begins.

For an agent module

Support for a module,not only a full build.

The fixed-scope agent modules can be supported on their own. It is declinable: a module keeps working if you decline it, and the scope is written down before it starts.

  • Support, for a moduleDeclinable

    Monitoring, drift and quality checks, the approval settings kept where you set them, and the written report.

See the three modules

Where this pays for itself,and where it does not.

Where it pays for itself

  • There is no in-house developer, and the person who would notice a problem has eleven other jobs.
  • The system connects to something, and other people's interfaces change on other people's schedules.
  • An agentic system is running, where drift is invisible until somebody complains.
  • A report goes to a board, and it has to say what changed and what it produced.

Where something smaller fits

  • Somebody already owns it. A developer whose job includes this system is better placed, and we would rather hand over cleanly.
  • It is a few static pages with nothing connected. Security updates are the one thing that does not wait, and that is a much smaller arrangement.
  • The system is being replaced soon. We would rather talk about the replacement.
  • What you want is hosting. Hosting keeps the lights on and costs a fraction of this.

Questionspeople ask.

  • What happens if we stop?

    The system keeps running and stays yours. There is nothing to hand over, and we do a final documentation pass so your next team starts informed.

  • Can our in-house team do part of it?

    Yes. A common split is that we handle monitoring, updates, and the technical improvement work while your marketing team publishes content. We write down who owns what so nothing sits in the gap.

  • How is this different from a hosting plan?

    Hosting keeps the lights on. This makes the system better and tells you whether it worked. The monitoring and patching are included, but the reason to take it is the improvement and the reporting.

  • Do we have to take this after a build?

    No. It is optional on every engagement, and declining it changes nothing about what you own or what was delivered.

  • Will you support a system you did not build?

    Yes, and the Performance Audit is the usual way in, because we need to know what we are taking responsibility for. Where something cannot be supported safely, we say so before support starts.

  • Who decides what gets improved?

    You do, from a shortlist we bring with the evidence attached. What is not chosen stays on the list with its evidence rather than disappearing.

A material study photographed in bright daylight. A tall fan of clear turquoise glass fins rises on the right of the frame with a polished pearl silver ribbon curving through it, standing in a shallow film of still water. The left of the frame is empty pale mint.

The years after launch, owned rather than assumed.