SEC-01
Least-privilege access
Each integration gets the narrowest scope that lets the work function. Nothing more.
Stage 04 · RunApplication 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.
- Access stays in your accounts
- Every change on record
- Written, auditable deliverables
- C01Take over properlyIn scope
- C02Get the basics rightIn scope
- C03Document while workingIn scope
- C04Reduce the dependency gap steadilyIn scope
- C05Absorb small changesIn scope
- C06Report what actually happenedIn scope
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.
- 5
- Warning signals
- that say this is the work
- 6
- Controlled steps
- each ships something you keep
- 4
- Written refusals
- lines we do not cross
Self-audit
Signals this is the work
Tick the ones that are true where you are. Nothing is sent anywhere — the answer is for you, not for us.
If more than one of these is true today, the problem is usually further along than it looks from the outside. That is not a sales line; it is what the cost of waiting does.
Readiness checklistApplication management
0 of 5 true
Nothing ticked yet.
How we do it
The sequence
Each step ships something you keep. You can stop after any of them and still be better off than when you started.
Start with step one- 01
Step 1 of 6
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
Step 2 of 6
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
Step 3 of 6
Document while working
Runbooks written from doing the work, not from reading the code. Documentation produced at the end is documentation nobody trusts.
- 04
Step 4 of 6
Reduce the dependency gap steadily
Regular small upgrades rather than one heroic jump in three years, which is how upgrades become impossible.
- 05
Step 5 of 6
Absorb small changes
A capacity allowance for the routine requests, so they stop requiring commercial negotiation.
- 06
Step 6 of 6
Report what actually happened
Incidents, changes, upgrades and where the risk now sits. Not an uptime figure with nothing behind it.
Assurance
Secured and auditable by default
These controls apply to every engagement, including this one. They are engineering decisions, not a certificate on a wall — and you can check each of them.
SEC-02
Credentials in your name
Accounts and keys live in your tenancy. You can revoke any of them without asking us.
SEC-03
Every change logged
Changes, deployments and incidents leave a written trail you can audit.
SEC-04
Restores tested, not assumed
A backup only counts once it has been restored. We test, and we report the result.
SEC-05
Separate environments
Development never touches production credentials or unmasked customer data.
SEC-06
A documented exit
Runbooks written as we go. Leaving means revoking our access — nothing is held back.
What we will not do
The refusals
The things we turn down are a better description of how we work than the things we sell.
Standing commitmentsApplication management
- 01
We will not: Take on a system without saying what we think is wrong with it.
- 02
We will not: Report green while backups have never been restore-tested.
- 03
We will not: Let a dependency gap grow because upgrading is not billable.
- 04
We will not: Hold knowledge hostage. Documentation and access stay yours.
Questions
Before you ask
Anything else, ask on the first call. There is no charge for working out whether this is the right fit.
Talk about a problemWill you manage software you did not build?
Yes — most of it. It starts with an assessment, because taking responsibility for something means understanding it first. That assessment is honest about anything we would want fixed before we could reasonably say it is covered.
What if we want to move away later?
Everything is in your accounts and repositories throughout, and the runbooks are written as we go rather than at the end. Leaving means revoking our access, which is the way it should be. An arrangement you cannot exit is not a service.
Does this include new features?
Small changes and routine requests are included within an agreed capacity. Substantial new capability is scoped separately, because otherwise either the maintenance gets squeezed or the fee stops being predictable — and both of those end badly.
What happens out of hours?
That depends on what the system is worth. An internal tool that can wait until morning and a platform taking orders overnight justify very different arrangements and very different costs. We would rather agree that explicitly than imply cover that does not exist.
Tell us what isn’t working.
One process, one system, one decision you are stuck on. An engineer replies within one working day with how we would approach it, and whether it needs building at all.