Ongoing support
Someone to call, eighteen months after launch.
Every system needs changing. Whether it lasts a decade or gets rewritten in three years comes down to one thing: whether changing it stayed routine. That is what a support arrangement buys you.
You might recognise
No one has deployed a change in months, and everyone is nervous about the first one.
The developer who built it is no longer contactable.
Updates have been deferred for so long that applying them is now its own project.
You need changes made occasionally, but not a permanent engineer on the payroll.
What that involves
- A retained arrangement, with a response time agreed in writing up front
- Small, frequent releases rather than one big launch
- Keeping dependencies, runtimes and security patches current
- Monitoring, backups, and someone to call when it matters
The same three stages
How it runs, for this kind of work.
01
Discovery
For a system we did not build, this starts as a read: what it does, what it runs on, what is out of date, and what would happen today if the server disappeared.
02
Implementation
Changes go out in small pieces, frequently. Small releases are safe to make and easy to undo, and that is what keeps a system changeable.
03
Full testing
The test suite is the thing being maintained. It is what makes the next change routine, including changes made by someone who is not us.
What you end up holding
- An agreed response time, in writing
- A current, patched, supported system
- A test suite that grows with the software
- Monitoring, backups and a tested way to restore
Where we have done this
Sounds like the situation?
Describe it in your own words — the system, what stopped, or what you wish it did instead. You will get an honest read on whether we can help and what a discovery would cover.