Services · 03
Support and maintenance
Software does not finish. It collects dependencies, certificates, API changes and the occasional failure at an inconvenient hour, and somebody has to own that.
Taking over what already exists
A lot of our maintenance work starts with a system somebody else built. The developer has moved on, the documentation was never written, and nobody is quite sure what would happen if the server had to be rebuilt.
We start with a paid assessment: how it is deployed, what it depends on, where it is likely to break, and what stabilising it would cost. You get that as a written document either way. It is not a sales exercise.
What a retainer covers
- Monitoring and alerting, so failures are noticed by us rather than reported by your customers.
- Updates, with dependency and security patching on a regular cadence rather than in a panic.
- Incident response, within an agreed window and with a named path to a person.
- A change budget, so small improvements do not need a quote every time.
Larger work is quoted separately. That boundary is deliberate. It keeps the retainer honest instead of letting it drift into open-ended development with no visibility.
Hosting and running it
We can host and run the systems we maintain, or work alongside whoever already does. Either way the aim is the same: somebody is accountable for it being up, and it is not you.
Writing things down
Most systems we inherit have their knowledge living in one person's head. Early retainer work usually includes runbooks, deployment steps and a map of what depends on what, so the system survives any individual, including us.
We are based in Johannesburg and work with clients across South Africa and the wider Global South, remotely by default.
Common questions
Will you take on a system you did not build?
Yes, and often that is the request. We start with a paid assessment: how it is deployed, what it depends on, where the risks are, and what it would cost to stabilise. You get that assessment as a written document whether or not you carry on with us.
What does a retainer include?
Monitoring and alerting, dependency and security updates, incident response within an agreed window, and a budget of small changes each month. Larger work is quoted separately so the retainer does not quietly turn into a development contract.
What if there is no documentation?
Common, and not a blocker. Part of the first month is writing enough down that the system is no longer held in one person’s head: runbooks, deployment steps, and a map of what depends on what.
Can you just be a fallback?
Yes. Some clients keep us on a small retainer purely so somebody who knows the system is reachable when the person who built it is not.