Application support and maintenance services
What happens after launch: monitoring, patching, support and the roadmap that follows it.
Most software does not fail dramatically. It degrades — a dependency goes unpatched, a certificate is renewed by hand by someone who then leaves, a slow query gets slower, and one day the thing everybody relies on is a risk nobody owns.
Support is not a helpdesk queue bolted onto a finished build. It is knowing what normal looks like, so abnormal is visible before a customer reports it, and having somebody who can change the code rather than only restart it.
Tickets reach whoever wrote the code. That is the whole model, and it is why the roadmap keeps moving instead of stalling behind a backlog of things only the original team understood.
What the work includes
Monitoring and alerting
Alerts on the things that indicate a user is having a bad time, not on every metric that can be graphed. Noisy alerting trains people to ignore it.
Patching and dependency hygiene
Security updates applied on a schedule, with the test suite as the safety net. Most breaches exploit something that had a patch available.
Incident response
A named path to somebody who can actually change the code, and a written postmortem afterwards focused on the cause rather than the person.
Performance and cost review
Watching where query time and cloud spend are going, since both grow quietly until somebody looks.
Backups you have restored
Tested restores, not just configured backups. An untested backup is a belief, not a plan.
A roadmap that keeps moving
Support capacity that includes improvement, so the product still changes rather than only being kept alive.
Scope against a decision, not a wishlist
The first conversation is about what you are trying to decide or change, and we say plainly which parts of the request we think are wrong. A scope that survives contact with the first sprint is worth more than one that flatters the brief.
Architecture written down before code
The decisions that are expensive to reverse — tenancy model, data ownership, auth, where state lives — get written down and argued about while they are still cheap. You keep that document; it is what lets another team pick the system up.
Two-week increments, working software each time
Every increment ends with something you can open and use, not a status update. If a plan is going wrong you find out in a fortnight rather than at handover.
Handover you could act on without us
Tests, logs, runbooks and the reasoning behind the architecture. We would rather you were able to leave than locked in, and the engagements that last are the ones where that was true from the start.
What it is built on
Questions we get asked
Do you support software somebody else built?
Yes, and it is a large part of this work. It starts with an audit — what it does, what is risky and what is undocumented — delivered as a written assessment before any support commitment is agreed.
What response times do you offer?
They are set per engagement against how much downtime actually costs you, and written into the agreement rather than implied. We would rather commit to something we can hold than quote a number that sounds impressive.
Is support a fixed monthly cost?
Usually a monthly retainer covering monitoring, patching and an agreed amount of change work, with larger pieces scoped separately. It is deliberately not per-ticket — that structure rewards the wrong things on both sides.
What if we want to move support in-house?
The runbooks, architecture decisions and access are yours throughout, so the handover is a transfer rather than an excavation. Engagements that end cleanly tend to come back.