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.
Also from us
Web applications
Customer portals, internal tools, dashboards and the APIs behind them.
Mobile applications
iOS and Android, from a single codebase or native where it counts.
AI and ML solutions
Models and pipelines aimed at a specific business problem, not a demo.
System software
The layer underneath — services, drivers, tooling, integrations.
Cloud services
Infrastructure you can reason about, and a deploy you can trust.
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.