Managed application support and maintenance
Keeping software that is already live working, inside your SLA and your ticket queue: triage, fixes at the cause, patch releases, dependency and platform upgrades, security response and incident handling. Second and third line, by engineers who also build, so a recurring fault gets fixed rather than restarted.
Why this is a partner problem
Support is the part of a managed service that is easy to sell and hard to staff. It arrives unevenly, it needs people who can read unfamiliar code under time pressure, and the moment you put your best engineers on it they stop being available for the work that pays better. The usual answer is a separate, cheaper tier that closes tickets without ever fixing anything, and the customer notices within a quarter.
Our answer is that the people on support are engineers. They can change the system, not just describe it, which is the only way a recurring incident ever stops recurring.
What we carry
Triage and diagnosis
Picking up what first line cannot answer, reproducing it, and saying what is actually wrong rather than closing it as not reproducible.
Fixes that hold
Defects fixed at the cause, with a regression test written against the whole class of bug rather than the one ticket, so the same incident does not come back next quarter.
Releases and patching
Patch releases shipped through your pipeline on your change process, with dependencies, framework versions and platform runtimes kept current instead of drifting into an upgrade crisis.
Security response
A published advisory in something you depend on is an unconditional reason to upgrade, not a backlog item. We track it, patch it and tell you what the exposure was.
Monitoring and incidents
Watching the alerts that already exist, adding the ones that should, and handling incidents with a written account afterwards of what happened and what stops it recurring.
Small changes
The steady stream of minor enhancements that keeps a customer satisfied and never justifies a project: handled inside the same capacity, on the same terms.
Your SLA, honestly assessed
We do not publish response and resolution targets, because a number invented before anyone has seen your system is worth nothing to you and nothing to your customer. Instead we read the SLA you already owe, tell you which parts of it we can genuinely carry and what coverage that takes, and then commit to that in writing.
The same applies to out-of-hours cover. Where an engagement needs it and we have agreed it up front, it is staffed by people recruited or assigned for those hours rather than by waking somebody up and hoping. We already run to European, Australian and US Pacific hours on other engagements, so the question is which window you need, not whether it is possible.
Taking on a system we did not build
Which is the normal case. Nine take-overs so far, the oldest written in 2008.
Read-only review first
We get access to the code, the infrastructure and the ticket history before we are responsible for any of it, and we look rather than change.
A written list of risks
What is fragile, what is unpatched, what is undocumented and what will wake somebody at night, ordered by production impact. Yours to keep whether or not we go further.
The coverage conversation
We read the SLA you owe your customer and tell you honestly which parts we can carry, what hours that takes and what it costs, before either side signs anything.
Handover, then live
A defined shadowing period with whoever holds the knowledge now, then we take the queue. If nobody holds the knowledge any more, the risk review is where we start instead.
Under your name, if that is the arrangement
Support is usually the most visible part of a managed service, so it is also where being white-label matters most. Our engineers can work from mailboxes and accounts you issue, answer in your ticketing system and write incident reports you forward unchanged; your customer deals with you throughout. White-label development covers how that is arranged, and it applies to support in exactly the same way.
How support is priced
Per person, monthly, so your own cost is predictable and you can price a support contract to your customer against it. Everyone logs time in our own portal, you see the hours throughout the month, and the same figures produce the invoice, so there is one record both sides reconcile against.
Where support sits beside new development, the two are usually one delivery pod rather than two contracts, so quiet weeks on one side pay for busy weeks on the other.
Questions about support arrangements
What does managed application support cover?
Keeping software that is already live in production working: triaging what comes into the queue, reproducing and fixing defects, answering the technical questions first line cannot, shipping patch releases, keeping dependencies and platform versions current, watching the alerts and handling incidents when something breaks. It is second and third line work; your first line stays where it is.
Do you work to our SLA?
Yes. We do not publish response and resolution targets, because a number invented in advance of knowing your system is worth nothing. We read the SLA you already owe your customer, tell you honestly which parts of it we can carry and what coverage it would take, and then commit to that in writing.
Can you provide out-of-hours or on-call cover?
Yes. Out-of-hours and on-call cover is agreed up front, written into the support terms, and staffed by people whose working hours match it, so an incident at night reaches someone on shift rather than someone woken up.
Can you support a system you did not build?
That is the normal case. Nine take-overs so far, the oldest written in 2008. Support of an inherited system starts with a read-only review and a written list of risks ordered by production impact, so the first weeks are spent understanding what you are actually responsible for rather than guessing under pressure.
Will the same people who support the system also change it?
Yes, and that is the point. The engineers on support are engineers, not a separate ticket-closing tier, so a recurring incident can be fixed at its cause instead of being restarted every Monday. Where you have both a build stream and a support stream with us, the two share code review and architecture decisions.
How is support priced?
Per person, monthly, so your own cost is predictable and you can price a support contract to your customer against it. Hours are logged in our portal and visible to you throughout the month, and the same figures produce the invoice, so there is one source for both sides.
Have systems to keep running?
Tell us what the systems are, what your SLA promises and where support currently hurts. We will read it and tell you which parts we can carry, including the parts we cannot.