Application management
Owning the software after the project ends
A system that nobody owns degrades on a predictable schedule. Dependencies age, certificates expire, disks fill, and the person who knew how it worked moves on.
In short
Application management is continuous ownership of software already in production: watching that it works, keeping dependencies and certificates current, responding when it breaks, and making the small changes the business needs without a project every time. It is distinct from a support contract that only answers tickets, because most of the work is preventing the ticket — the expired certificate, the full disk, the library with a published vulnerability.
When it applies
Signals this is the work
If more than one of these is true today, the problem is usually further along than it looks from the outside.
The people who built it have gone
An agency finished, a contractor left, or an employee moved on, and nothing was formally handed over.
Small changes need a project
A text change or a new field requires scoping, quoting and scheduling, so it does not happen.
Nobody knows if it is healthy
You find out something is wrong when a user says so.
Dependencies are years behind
The framework and libraries are several versions old, and the gap widens every month.
There is one person who knows
A single individual understands the system, and everyone knows this is a risk.
How we do it
The sequence
- 01
Take over properly
An assessment of what exists, what the risks are, and what must be fixed before anyone can responsibly say it is covered. We are explicit about what we would want changed first.
- 02
Get the basics right
Monitoring, backups with tested restores, access control, certificate renewal, patching rhythm. Most systems we inherit are missing at least two of these.
- 03
Document while working
Runbooks written from doing the work, not from reading the code. Documentation produced at the end is documentation nobody trusts.
- 04
Reduce the dependency gap steadily
Regular small upgrades rather than one heroic jump in three years, which is how upgrades become impossible.
- 05
Absorb small changes
A capacity allowance for the routine requests, so they stop requiring commercial negotiation.
- 06
Report what actually happened
Incidents, changes, upgrades and where the risk now sits. Not an uptime figure with nothing behind it.
What we will not do
The refusals
- Take on a system without saying what we think is wrong with it.
- Report green while backups have never been restore-tested.
- Let a dependency gap grow because upgrading is not billable.
- Hold knowledge hostage. Documentation and access stay yours.
Questions
Before you ask
Tell us what isn't working.
One process, one system, one decision you are stuck on. We will come back with how we would approach it, what it would take, and whether it needs building at all.