Service 05
Maintenance and production
Keeping alive what already runs — including the system I didn't write.
Context
Software isn't only building. Most of a system's life happens after delivery: the vendor's API changes, a dependency bumps a version and takes something else down, volume grows and what was fast turns slow, the company's process changes and the system doesn't follow.
This is exactly the front that one-off projects leave orphaned — it's out of scope, and every incident becomes a negotiation. In a monthly contract it's the default: every change goes through automated tests, ships via continuous integration, has a staging environment for you to see first, and rollback ready if something slips.
I also take on legacy systems somebody else built. It isn't the glamorous part, but it's usually where the losses live.
Signs this is your case
- Nobody knows who to call when the system goes down out of hours
- There's a live system nobody feels safe changing
- Every update is postponed for fear of breaking what works
- The original vendor disappeared and the code has no owner
What you're left with
- Automated tests on the critical paths, running on every change
- Continuous integration and delivery, with staging before production
- Rehearsed rollback — the previous version is back in minutes
- Monitoring and active alerting, so I know before you notice
What it isn't
- 24×7 on-call with a contractual response-time guarantee
- Maintaining a system whose source code can't be accessed
A workflow in practice
A failure no longer waits for someone to notice
An illustrative workflow, not a client case study or a promised result.
See the monthly retainerDetect
An alert identifies a failure in the monitored workflow, with the context needed to investigate.
Fix
I reproduce the problem and test the fix. Risky changes get a plan to return to the previous version.
Verify
After deployment, I check the affected journey. The cause and prevention stay documented for the operation.
Where I start
I map live systems, access, backups and critical points. The first priority is knowing how to recover the system and notice when it fails.
What continues every month
Maintenance, updates and incidents are part of the monthly work. Support windows and priorities are agreed; this is not unlimited on-call coverage.
Questions about this front
Do you take on a system you did not build?
I do, and it is a good part of the work. It is not the glamorous part, but it is usually where the losses live: a live system with no owner is the one nobody feels safe changing, so it ages until it breaks.
Is this 24/7 on-call?
No. There is monitoring and active alerting, so I usually know before you notice — but I do not sell a contractual response-time guarantee outside working hours. Promising on-call that one person cannot sustain would be a lie.