Skip to content

Support and maintenance

Software is not finished when it ships. Dependencies age, security advisories land, the business changes and the requirements move with it. We keep systems healthy over years — the ones we built, and the ones you inherited from somebody else.

What it covers

Software isn't finished when it ships. We keep what we build — and what you already run — working: monitoring and incident response, security and dependency updates, bug fixes, and a steady stream of small improvements. You deal with someone who knows your system, not a ticket queue. We also take over software somebody else wrote.

  • Ongoing maintenance and updates
  • Monitoring, alerts and incident response
  • Security patching and dependency upgrades
  • Enhancements and new features
  • Taking over existing or legacy systems
  • Support agreements with agreed response times

How we approach it

Small and continuous, not a big-bang upgrade
Applied steadily, updates are routine. Deferred for two years they become a project with a budget and a risk register. We keep things current so that never has to happen.
Fix the cause, not the ticket
When the same issue comes back a third time, the bug is upstream of the symptom. We're paid to make the queue shorter over time, not to keep it moving.
Improvement is part of the arrangement
Support here isn't only keeping the lights on. There's a steady flow of small enhancements — the friction your team has learned to live with is usually the cheapest thing to fix.

Where we differ

Why bring this to us rather than anyone else.

A person who knows your system, not a ticket queue
You deal with the engineers who work on your software, not a first line reading a script who escalates to someone who has never seen it. This is the difference most clients notice first.
We take over other people's software
Many firms only maintain what they built, which leaves you stuck when the original team disappears. We'll read someone else's codebase, tell you honestly what state it's in, and take it on.
Not a retainer that bills for nothing
A quiet month should show up as improvements, upgrades or reduced running costs — not an invoice for availability. We'd rather you can point at what the arrangement bought.

When to call us

You probably need this if…

  • The team that built your software is gone and nobody has touched it since
  • Security updates are behind and nobody owns applying them
  • Small changes wait months because there's no one to make them
  • You find out about outages from your customers

Questions

Will you support software you didn't build?
Yes — it's a large part of this service. We start with a review of the codebase and infrastructure, then tell you what shape it's in and what a sensible arrangement looks like. Occasionally the honest answer is that parts should be replaced, and we'll show our reasoning.
How fast do you respond?
It's agreed in writing and depends on what the software does — an outage in a system your customers touch is not the same as a cosmetic bug in an internal tool. We set response times per severity so both sides know what's promised.

Next step

Tell us what you are trying to fix.

A couple of paragraphs is plenty. We will tell you honestly whether this is the right service for it, and whether we are the right team — usually within two working days.