Shipping is the middle of the job.

Fixing what breaks, making small changes, keeping dependencies current, monitoring for failure and holding the documentation. The last two are what stop the first one happening at 2am.

Running an application on your behalf — code, infrastructure, releases and on-call. It differs from a support contract by including the parts that keep it running, not only the parts that fix it.

Yes, and it is a large part of what we do. It starts by reading the codebase and writing down what nobody documented, which usually takes the first month.

Support is answering when something is wrong. Maintenance is the work that means it goes wrong less — upgrades, monitoring, refactoring and documentation. Buying only the first is how systems decay.

By the allocation, not by ticket. A fixed monthly amount of engineering time covering fixes, changes and upkeep, so nobody is arguing about whether something counts as a bug.

It should be written down and measured rather than promised. What matters more is who answers — an engineer who knows the system responds differently to a queue that does not.

You keep the code, the documentation and the runbook. The repository has been in your organisation since the first commit, so nothing is being held.

For systems where an overnight failure matters. It requires monitoring worth being woken by, which is usually the first thing we build.

Continuously and in small steps, staged before production. Deferred upgrades compound, and the cost of catching up roughly doubles each year they are left.

Yes. It goes better with their cooperation and works without it. Either way the first deliverable is a written account of what actually exists.

Keeping something running that nobody wants to rewrite yet. The work is containment — monitoring, documentation and careful change — until replacing it is a decision rather than an emergency.

You do, throughout. Access concentrated in a supplier is the most common single point of failure we are asked to fix.

Not in the sense most people mean it. We run applications and the infrastructure they sit on — hosting, monitoring, patching, releases and on-call. We do not staff an end-user help desk, administer your network or manage laptops and identity, so if that is what you are shopping for you want an MSP alongside us rather than instead of us.

You keep an in-house engineer or team, and we cover the parts they cannot: the on-call rota, the upgrade backlog, or the one system nobody internally wrote. It suits a business with real engineering capacity but not enough of it to be woken up reliably.

It depends on whether the vulnerable path is actually reachable in your system. A critical advisory in a dependency you call on every request is same-day and staged; one in a transitive package nothing exercises joins the normal upgrade cycle. The judgement is written down either way, so the decision is auditable rather than remembered.

By restoring one. Backups are taken on a schedule and periodically restored into a scratch environment to prove the process end to end. Until that has happened at least once, a backup is a belief rather than a recovery plan.