Services
Going live is where it starts
Software doesn't break at handover. It breaks in month eighteen, when whoever wrote it has left and nobody dares touch it.
Who this is for
- Companies running a system their original vendor no longer supports
- Organisations that need guaranteed response times on incidents
- Businesses that want to upgrade gradually rather than rewrite
Scope of work
- Taking over an existing system, even with thin documentation
- Monitoring and incident alerting
- Response-time commitments by severity
- Security patching and dependency upgrades
- Quarterly feature upgrades
- Backups and restore drills
Technology & capabilities
- Go
- Node.js
- PHP
- Java
- MySQL
- PostgreSQL
- Docker
Process
Typical timeline: Monthly contract, six-month minimum
Takeover
Read the source, rebuild documentation, run it on our machines
Stabilise
Monitoring in place, worst backlog issues cleared
Operate
Health report and a list of work done
What this service is
Maintenance, operations, and upgrades is a long-term care service for systems already running in production, covering bug tracking, security patching, keeping software libraries current, and building new features that come up after the original project has closed. It fits systems Cluvix built originally or systems built by another team that the client now needs handed over for ongoing operation. Response-time commitments for incidents are agreed explicitly in the contract, ranging from a few hours for critical issues disrupting operations to a few days for non-urgent improvement requests. Unlike ad-hoc bug fixes billed one at a time, a long-term maintenance contract allows proactive periodic review to catch problems before they affect users, instead of only reacting once an incident happens. This fits businesses without an internal team large enough to operate the system on their own once the original build team has handed off.
How it compares to other options
Compared to calling for a one-off fix whenever something breaks, a long-term maintenance contract has a stable total cost that's easier to budget annually, and guarantees someone already familiar with the system is ready to respond instead of having to find and re-explain the full context to a new party every time. One-off fixes can be cheaper if the system rarely has issues, but carry the risk of slower response since there's no clear SLA commitment. Compared to hiring a full-time in-house operations engineer, a maintenance service fits better when the workload isn't enough to justify one full-time person, and avoids disruption risk when that person quits or takes extended leave. Worth weighing: for a very large system needing round-the-clock daily coverage, a dedicated in-house operations team may still fit better than a contracted maintenance service.
What drives cost & timeline
Response time commitment level
Committing to a few hours' response even outside business hours requires rotating on-call staffing, costing more than a commitment to respond within normal working hours.
System scale and complexity
A system with many modules integrated to third parties needs more periodic review time than a simple single-module system.
Frequency of new feature requests
If new feature work happens regularly alongside maintenance, cost scales with the actual development workload each month.
How to choose a partner
Assess the impact if the system goes down
The more a system directly drives daily revenue, like a sales website, the shorter its response-time commitment needs to be.
Check your internal team's current capacity
If the internal team can only handle daily firefighting with no time for proactive review, an external maintenance service fills that gap.
Review the system's incident history
A system with a past history of security incidents or downtime should prioritize a maintenance package with regular security review, not just reactive fixes.
Common risks
Legacy system runs on unsupported libraries
Old software libraries no longer receiving security patches are a silent vulnerability until exploited.
How we handle it: The library list in use is reviewed periodically and upgrades planned before an old version loses support entirely.
No documentation from the original build team
If a system was built by another team with no documentation left, the handoff phase needs time to relearn the entire codebase.
How we handle it: An initial codebase discovery phase happens before signing a formal SLA, to estimate a realistic response time.
New feature requests get mixed in with urgent fixes
Without separation, non-urgent feature requests can eat into time meant for urgent incident response.
How we handle it: Urgent incident and new-feature queues are kept separate, handled according to their agreed urgency level.
Talk to us about this service
Tell us about your problem — we'll reply within one business day.