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
Describe the actual case. The technical answer comes in the conversation.
Other fronts