Cloud & Operations
Maintenance & Support Services
Software is never finished. It is either maintained or left to rot. We keep live systems running, secure and current, including the ones someone else built and walked away from.
What Maintenance & Support means in practice
Who it’s for: Organisations running live software they depend on (whether we built it or someone else did), who need it kept secure, current and available, without carrying a full-time engineering team or gambling that an untended system will simply keep working.
Launch is not the finish line; it is the point at which a system starts ageing. The code you shipped is correct against the world as it was on release day, and the world does not hold still. Dependencies you pulled in publish security advisories. The operating system and the runtime move on and quietly deprecate the versions you built against. The third parties you integrate with change their APIs, tighten their rate limits and retire endpoints on their own schedule, not yours. Browsers and mobile platforms ship updates that break assumptions you never wrote down. None of this is a failure of the original build: it is entropy, and it is the reason an unmaintained system does not stay still but actively decays. Maintenance and support is the work of keeping a live system running, secure and current after the applause has stopped.
This service is the direct expression of a principle we hold across everything we do: we operate what we build. The engineer who understands why a piece of code is shaped the way it is makes a far better job of keeping it alive than a support desk reading from a runbook they have never had to use in anger. But this page is also, very deliberately, about systems we did not build. It is one of the most common situations we are called into: the original team is gone, the agency has moved on or folded, the one developer who understood it has left, and a business is now sitting on software it depends on daily and nobody fully understands. That system is usually fragile precisely because it has been running untended, and the honest first job is not new features but stabilisation.
We are blunt about a thing the industry prefers to leave vague: you do not need a large monthly retainer to keep a stable system healthy. Support should be right-sized to the risk the software actually carries: a quiet internal tool that a handful of people use is a different proposition from a payments flow or a public platform whose downtime costs money by the minute. We would rather scope you the smallest arrangement that genuinely covers the risk than sell you hours you will not use. What we will not do is pretend the risk is zero, because the most common real-world breach is not an exotic attack. It is a neglected dependency with a known, published, months-old vulnerability that nobody got round to patching.
What you get
- Bug fixes for the defects that surface in real use, diagnosed at the root rather than papered over, so the same problem does not return under a different symptom next month
- Security patching and dependency upkeep on a regular cadence, tracking advisories against what you actually run, and updating before a known vulnerability becomes an incident rather than after
- Monitoring and alerting that watches the system for you, so a problem reaches us through a page rather than through an angry customer, and incident response with agreed response times when something does break
- Performance tuning as load and data grow, finding and fixing the query, the memory leak or the slow endpoint that was fine at launch and is not fine now, before it becomes an outage
- Small feature work and change requests. The steady stream of tweaks, new fields, report changes and integration adjustments that keep software fitting the business as the business moves
- OS, runtime and platform-compatibility updates, keeping the system building and running as the operating system, language runtime, browser and mobile platforms move underneath it
- A clear SLA: named response times by severity, an agreed way to raise issues, and a monthly account of what was done, what was patched and what we are watching, so you can see the value rather than take it on faith
What Maintenance & Support does for you
The lights stay on, and someone is watching
The difference between a system that is monitored and one that is not is the difference between finding out about a problem from an alert and finding out from a furious customer an hour after it started. We put eyes on the system (uptime, error rates, the health of the integrations you depend on), so that a failure pages an engineer who can act, under a response time you have agreed in advance. The point is not heroics; it is that a problem has an owner and a clock the moment it happens, rather than sitting undetected until the damage is done.
Security debt paid down before it is called in
Most real breaches are not clever. They are a known vulnerability in a library you depend on (published, catalogued, with a fix available for months), that simply never got applied because nobody owned the patching. We track the advisories that actually affect what you run and apply the updates on a regular cadence, testing that they do not break you, so the window between a vulnerability becoming public and your system being protected is short and deliberate rather than open and unmonitored. This is the least glamorous work in software and among the most valuable.
Support sized to the risk, not the invoice
A stable system with modest traffic does not need a large standing retainer, and we will say so. We scope support to what the software actually risks: how much it matters if it is down, how sensitive its data is, how fast it is changing, so you pay for cover that matches the exposure rather than a fixed block of hours designed to be comfortable for us. When the risk is genuinely low, the right answer is a light-touch arrangement, and an honest supplier tells you that instead of inflating the scope.
Why teams choose us for Maintenance & Support
- You want the people keeping your software alive to actually understand it, either because we built it and never stopped operating it, or because we took the time to learn an inherited system properly before touching it, rather than a support desk following a script for code they have never read.
- You have a system nobody dares change, and you need someone who will stabilise it deliberately, tests around the risky parts, documentation of how it really works, observability so failures are visible, rather than either rewriting it on a whim or refusing to go near it.
- You want the security and dependency upkeep done properly and provably, on a cadence, against real advisories, because you have understood that the neglected library is the likeliest way in, not treated as an afterthought squeezed between feature requests.
- You want a straight answer on how much support you actually need, including being told when a stable system needs very little, rather than being sold the largest retainer a salesperson thinks you will sign.
What Maintenance & Support includes
The concrete pieces of work this covers, scoped to what your problem actually needs.
Corrective maintenance and bug fixing
When something is broken we diagnose it to the root rather than patching the symptom, because a fix that suppresses an error message while leaving its cause in place is a bug that will return in a worse form later. We reproduce the problem, understand why it happens, fix it where it lives, and where it makes sense add a test that fails on the old behaviour so the same defect cannot quietly come back. Corrective work is triaged by impact: the thing losing you money or blocking users comes before the cosmetic irritation.
Security patching and dependency management
We keep an inventory of what your system actually depends on and watch it against published advisories, so an update is driven by a real, relevant vulnerability rather than by upgrading blindly for its own sake. Patches are applied on a cadence, tested so they do not break you, and prioritised by severity and exposure: an internet-facing, exploitable flaw jumps the queue; a low-risk advisory in a dependency you barely touch is scheduled rather than rushed. The aim is to keep the window of known-but-unpatched exposure short and deliberate.
Monitoring, alerting and incident response
We instrument the system so its health is visible, uptime, error rates, latency, queue depth, the status of the integrations it leans on, and wire alerts to the things that actually indicate trouble rather than to noise that trains everyone to ignore the pager. When an incident happens, response follows the agreed SLA: acknowledge within the committed time, contain, fix, and afterwards a short account of what went wrong and what we changed so it is less likely to recur. A repeated incident is treated as a design problem, not a fact of life.
Performance tuning as the system grows
Software that was quick against a small database and light traffic does not stay quick as both grow, and the slowdown is rarely where a guess would put it. We find the real bottleneck by measuring. The query that got slow as the table filled, the N+1 fetch, the endpoint doing work it could cache, the slow memory leak that forces a nightly restart, and fix it at the level it lives, so the system keeps up with its own success rather than being rescued by ever-bigger hardware buying a little more time.
Adaptive updates: OS, runtime and platform compatibility
The ground moves under every live system. Operating systems reach end of support, language runtimes deprecate the versions you built on, browsers change behaviour, and mobile platforms enforce new requirements on their own timetable: an app that is not updated eventually stops being accepted at all. We keep the system building and running against a supported stack, migrating off versions before they lose security support rather than after, so compatibility is maintained steadily instead of becoming an emergency the day a platform pulls the rug.
Small feature work and evolutionary change
Live software is never static, because the business it serves is not. There is a steady flow of small changes: a new field, an adjusted report, a tweak to a workflow, an accommodation for a partner who has changed their API. That keep the system fitting reality. We handle these as part of ongoing support, sized and prioritised against everything else, so the software evolves in small, safe, reviewable steps rather than drifting out of alignment until only a big, risky project can bring it back.
Where it fits
Taking over an orphaned, business-critical system
A company depends daily on software whose original builders are long gone. An agency that moved on, a contractor who left, a developer nobody can reach. It works, mostly, but every change is terrifying because nobody understands it and there is no safety net. We take it over the careful way: learn it as it actually is, get it into version control and a reproducible build if it is not already, add observability so we can see what it does in production, put tests around the parts that would hurt most if they broke, and only then start making changes with confidence. The outcome is a system that is understood and maintainable rather than a liability everyone tiptoes around.
Post-launch care for a system we or someone else just shipped
A product has just gone live, or a build has just been handed over, and there is no plan for the day after. We put the operational basics in place: monitoring, alerting, a patching cadence, an agreed way to reach an engineer when it falls over, and take on the ongoing bug fixes, updates and small changes, so the momentum of launch is not immediately lost to entropy. The system gets the steady attention that keeps early software from quietly rotting in its first year.
Relieving an over-stretched in-house team
An internal team perfectly capable of maintaining a system is buried under delivering new work, and maintenance keeps losing the fight for attention until something breaks. We take the keep-the-lights-on load (patching, monitoring, the incident response, the small fixes), off their plate, freeing them to focus on the roadmap while the existing system stays healthy. We work inside their tooling and standards, so this is extra safe hands rather than a second, disconnected team.
Closing a security and patching gap under scrutiny
An insurer, a customer, a partner or a regulator has started asking how a live system is kept patched and monitored, and the honest current answer is "not systematically". We establish the missing discipline. A dependency inventory watched against advisories, a patching cadence, monitoring and a documented incident process, and bring the outstanding updates up to date, so the answer to how the system is maintained becomes a real, demonstrable process rather than an uncomfortable silence.
How we approach Maintenance & Support
For a system we built, maintenance is continuity: the same engineers who know why the code is shaped the way it is keep it healthy, patch it, and evolve it as the business changes, with the observability and runbooks already in place from day one. For a system we did not build (the far more delicate case), the approach is to earn the right to change it before we change it. That means resisting the urge to start rewriting, learning the system as it actually is, and putting safety nets around the risky parts first, so that the first change we make is one we can make confidently and reverse if we are wrong.
Underneath both is the same discipline: match the effort to the risk. We measure before we tune, we patch on a cadence rather than in a panic, and we treat the failure path (what happens when a dependency, an integration or the platform breaks), as the normal case to be prepared for, not an edge case to be surprised by. And we are candid about right-sizing: a stable, low-traffic system may need little more than watchful patching and an agreed response time, and we will tell you that rather than manufacture work to fill a retainer.
How the engagement runs
We start by understanding the system and the risk it carries, not by quoting a block of hours. What is the software, what does it cost the business when it is down or wrong, how sensitive is its data, how fast is it changing, and what is the current state of its monitoring, its dependencies and its documentation? For an inherited system this doubles as a survey of what we are taking on: where the fragile parts are, what is undocumented, what has not been patched. That assessment tells us the right shape and size of support, which we would rather get right than default to the largest arrangement.
From there support runs as a steady rhythm rather than a series of surprises. Patching happens on a cadence and out-of-cadence when a serious advisory demands it. Monitoring watches continuously and pages us when something crosses a threshold that matters. Bugs and small changes are triaged by impact and worked through in priority order. Incidents follow the agreed SLA. And each month you get a clear account of what was fixed, what was patched, what we are watching and what we would recommend next, so the value is visible and the support stays honestly matched to the risk as both the system and the business change.
How we take over and stabilise an unfamiliar system
Taking over a system someone else built is a distinct discipline, and the biggest mistake is to start changing it before you understand it. The urge to rewrite the parts that look ugly is strong and almost always wrong: that code is load-bearing, its ugliness often encodes a hard-won lesson or a business rule nobody wrote down, and rewriting it blind is how a stable-but-fragile system becomes an unstable one. So the first phase is deliberately about learning, not changing: getting the system into version control and a reproducible build if it is not already, standing it up in an environment we can poke at safely, reading the code alongside its behaviour, and writing down how it actually works as we go, because the documentation that was never written is the single biggest reason the system feels dangerous.
Before we make meaningful changes, we build the safety nets that let us change it with confidence. Observability comes first: logging, metrics and alerting, so we can see what the system is really doing in production instead of guessing, and so a change that misbehaves shows itself quickly. Then we put automated tests around the areas that are both risky and important (the parts where a mistake would cost the most), even if the rest of the codebase has no tests at all, because you do not need full coverage to make change safe, you need coverage around the things you are about to touch and the things that must never break. With the system understood, observable and tested where it counts, the first real change becomes one we can make confidently and reverse if we are wrong, and stabilisation turns a liability into something that can be maintained and evolved rather than merely feared.
Security patching and dependency upkeep
The uncomfortable truth about live-system security is that the dramatic attacks make the headlines but the neglected dependency causes the breaches. Modern software is built on a deep stack of third-party libraries, and every one of them is a component whose maintainers publish security advisories on their own schedule. When a vulnerability in a widely-used library becomes public, it becomes public for attackers too, and automated scanning for known, unpatched flaws starts almost immediately. A system that is not being watched and patched is not safe because nothing has gone wrong yet; it is exposed, and the only question is whether anyone has noticed the open door. This is why dependency upkeep is not a nice-to-have bolted onto maintenance, for most live systems it is the single highest-value security work there is.
We handle it as a deliberate, ongoing process rather than an occasional clear-out. We keep an inventory of what the system actually depends on, watch that inventory against published advisories so we know which ones genuinely apply to you, and apply updates on a regular cadence: testing that each update does not break the system before it ships, because an upgrade that takes you down is its own kind of incident. Severity and exposure set the priority: an actively-exploited, internet-facing flaw is patched out of cadence, immediately; a low-risk advisory in a component you barely use is scheduled into the normal rhythm. Alongside the dependencies we keep the runtime and platform current, so you are not stranded on a version that has itself stopped receiving security fixes. The goal throughout is to keep the gap between a vulnerability becoming known and your system being protected short, deliberate and visible, rather than open, indefinite and discovered only in an incident report.
Signs it’s time
- You have inherited or orphaned software. The original developer, agency or team is gone, the system is business-critical, and nobody left in the building fully understands how it works or dares to change it
- You are worried about security. You know there are dependencies that have not been updated in a long time, you have seen advisories you are not sure apply to you, or a customer or insurer is now asking how you keep the system patched
- Your in-house team is over-stretched. The people who could maintain the system are buried in delivering new work, and keeping the lights on keeps slipping down the list until something breaks
- You have just launched, or just taken delivery of a build, and you have no plan for what happens next, no monitoring, no patching cadence, no agreed way to reach an engineer when the system falls over at an inconvenient hour
Our working method
The principle that organises everything here is that software is never finished (it is either maintained or left to rot), and that maintenance should be matched to the risk the software carries rather than to a comfortable retainer. So we measure before we act: we tune performance against real bottlenecks we have found, not ones we have guessed at, and we patch against advisories that genuinely apply rather than upgrading blindly. We treat the failure path as the normal case, because in a live system that talks to a network, depends on third parties and runs on a platform that keeps moving, something will break, and the job is to see it early, respond to it under an agreed clock, and make the repeat less likely.
For inherited systems the method adds one firm rule: understand before you change, and build the safety net before you rely on it. We resist the rewrite reflex, document as we learn, add observability and tests around what matters, and make the first change a small and reversible one. And running through all of it is honesty about scope. Because we operate what we support and would rather keep a system quietly healthy for years than firefight it, we tell you when a stable system needs little and when a critical one needs more, sizing the cover to the real exposure instead of to the invoice.
Technologies we build it with
Chosen per problem, not per fashion. This is the stack we most often reach for on this work.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Want a straight answer on Maintenance & Support?
A short call with a senior engineer, before you write a brief. If Maintenance & Support is the wrong answer for your situation, we will say so and tell you what we think is right.
What changes
It keeps working
Monitoring catches problems before your users do, and an agreed response time means a failure gets an engineer, not a shrug, so an outage is measured in minutes, not the hours it takes someone to notice.
It stays secure
Dependencies and the platform are patched on a cadence against real advisories, closing the neglected-library hole that is the most common route into a live system before it becomes a breach notification.
It stops being fragile
An inherited system that nobody dared touch becomes one that is understood, documented and observable, safe to change, because there are tests around the risky parts and a way to see when something goes wrong.
Industries we serve
Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.
How pricing works
- A retainer sized to the risk, for ongoing support. A monthly arrangement covering patching, monitoring, incident response under an agreed SLA, and a budget of hours for bug fixes and small changes, with the size set by how much the system matters, how sensitive its data is and how fast it changes rather than by a default package.
- A one-off stabilisation or takeover engagement, for an inherited or orphaned system, priced by an initial assessment, covering the work of understanding it, getting it into a reproducible build, adding observability and tests around the risky parts, patching what is overdue and documenting how it actually works, so it becomes safe to maintain.
- Pay-as-you-go support for genuinely stable, low-risk systems, where a standing retainer would be selling you hours you will not use, light-touch patching and an agreed response time when you need us, so you carry cover proportional to a low but non-zero risk without paying for a full arrangement.
Typical timeline
- 01
Assessment and onboarding
One to two weeks understanding the system, the risk it carries and its current state, access, build, dependencies, monitoring and documentation. For an inherited system this is also where we survey the fragile and undocumented parts and agree the right shape and size of support.
- 02
Stabilise and secure the baseline
The first weeks of active work: standing up monitoring and alerting, bringing overdue security patches up to date, adding tests around the riskiest areas, and closing the gaps that make the system dangerous to change or blind to failure.
- 03
Steady-state support
The ongoing rhythm, patching on a cadence, monitoring continuously, responding to incidents under the SLA, and working through bug fixes and small changes by priority, with a monthly account of what was done and what we are watching.
- 04
Periodic review and right-sizing
At regular intervals we step back: is the level of support still matched to the risk, has the system stabilised enough to scale support down, or has it grown critical enough to need more, so the arrangement keeps tracking reality rather than ossifying.
What working with us actually means
We operate what we build
Maintenance is not a separate department we hand your system to after the build; it is the same senior engineers who understand why the code is shaped the way it is, staying with it. That continuity is why the parts that only matter under load and failure (monitoring, patching, runbooks, incident response), are real rather than theoretical, and why a fix addresses the cause instead of the symptom.
We take over other people’s systems properly
Inheriting an orphaned, fragile system is one of the most common reasons businesses call us, and we do it the careful way: learn it before changing it, resist the rewrite reflex, document as we go, and build observability and tests around the risky parts before we rely on them. We turn a system nobody dares touch into one that is understood and safe to evolve.
We treat security patching as the core work it is
We have seen enough of the real world to know that the neglected dependency, not the exotic exploit, is how live systems get breached. So dependency and platform upkeep is a deliberate, tracked, cadenced discipline in every arrangement. The least glamorous work in software, done properly, because it is among the most valuable.
We right-size the support and tell you the truth
We would rather keep a system quietly healthy than sell you a retainer you do not need. Support is scoped to the risk the software actually carries, and when that risk is genuinely low we say so and scope it down, because an honest, proportionate arrangement is what keeps a client for years, and firefighting is what we are here to prevent.
How to engage us
Three ways to work with us on this, chosen to fit the problem, not our margin.
- Dedicated team A standing team that works only on your product, in your rituals and your tooling. Best when the roadmap outlives the project. Ongoing product development
- Staff augmentation Named senior engineers embedded into your existing team, reporting into your leads. Best when you know what to build and need capacity. Filling a capability gap
- Software outsourcing A defined outcome delivered end-to-end by an accountable team. Best when you want the result owned, not just the hours filled. Outcome-owned delivery
Related services
Part of Cloud Engineering. Other work we do alongside this.
Weighing the options
The decisions people are usually making at the same time as this one.
Common questions
Can you maintain software that your team did not build?
Yes. It is one of the most common reasons people come to us. A business depends on a system whose original developer, agency or team is gone, and it has become fragile because nobody understands it or dares change it. We take it over the careful way: we learn it as it actually is, get it into version control and a reproducible build if it is not already, add monitoring so we can see what it does in production, and put tests around the parts that would hurt most if they broke, before we start making changes. We deliberately resist the urge to rewrite it, because that code is load-bearing and its quirks often encode business rules nobody wrote down. The outcome is a system that is understood, documented and safe to maintain rather than a liability everyone avoids.
How big a support retainer do we actually need?
Very possibly a smaller one than you expect, and we will tell you honestly. The right size is set by the risk the software carries: how much it costs when it is down or wrong, how sensitive its data is, how fast it is changing, not by a default package. A quiet, stable internal tool might need little more than watchful patching and an agreed response time, and for genuinely low-risk systems a pay-as-you-go arrangement is more sensible than a standing retainer. A public platform handling money or personal data is a different proposition and warrants more. We would rather scope you the smallest arrangement that genuinely covers the risk than sell you hours you will not use, and we review it periodically so it keeps matching reality.
Why does software need ongoing maintenance at all if it already works?
Because "works" is a statement about the world on release day, and the world does not hold still. The dependencies your system is built on publish security advisories, and a known, unpatched vulnerability is the most common route into a live system. The operating system and language runtime move on and deprecate the versions you built against. Browsers and mobile platforms change behaviour and enforce new requirements on their own timetable: an unupdated mobile app can eventually stop being accepted at all. The third parties you integrate with change their APIs and retire endpoints. None of this is a fault in the original build; it is entropy. An unmaintained system does not stay still, it decays. The only question is whether you notice before your users or an attacker does.
What do your SLAs and response times actually cover?
The SLA sets out, in advance, how quickly we acknowledge and begin work on an issue depending on its severity. A system-down incident on a critical service gets a fast, committed response, while a minor cosmetic bug is scheduled into the normal rhythm. It also defines how you raise issues and what monitoring is in place so that many problems reach us through an alert rather than through you. We size the response times to what the system genuinely needs rather than promising round-the-clock cover on software that does not warrant it, because an SLA you are paying for and do not need is as wrong as one that is too thin. Alongside the response commitments you get a regular account of what was fixed, patched and watched, so the SLA is something you can see being honoured rather than take on trust.
We think our dependencies are badly out of date, is that dangerous, and can you fix it?
It is the most common real-world security exposure there is, and yes, we fix it. When a library you depend on has a published vulnerability, it is public for attackers too, and automated scanning for unpatched systems begins almost immediately, so out-of-date dependencies are not a tidiness problem, they are an open door nobody is watching. We start by taking an inventory of what you actually run and checking it against advisories to see which genuinely apply to you, then bring the overdue updates up to date, testing each so the upgrade does not break you. After that it becomes an ongoing cadence rather than a one-off scramble: we watch your dependencies and the platform against advisories and patch on a regular rhythm, prioritising by severity and exposure, so the gap between a vulnerability becoming known and your system being protected stays short and deliberate.
Thinking about Maintenance & Support?
Tell us the problem in your own words, not in requirements. A senior engineer reads it and comes back with a straight view on whether Maintenance & Support is the right answer here, or what would be.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.