Custom software that a business depends on is not like a packaged product. It was built for a specific operation, with specific logic, specific integrations, and specific decisions made at specific moments in the project. When something goes wrong - or needs to change - the person fixing it needs to understand all of that context.
Generic support cannot provide that. A helpdesk staffed by generalists working from documentation can support a product with known issue types and documented fixes. It cannot support a bespoke system where every problem is potentially unique, and where the fix depends on understanding why the system was built the way it was.
This is why the SLA support question for bespoke software is not 'what response time do you need?' - it is 'who owns this system, and do they actually understand it?'
Why generic support structures fail for custom software.
Packaged software - an ERP, a CRM, a cloud platform - is supported by a helpdesk that deals with known issue types. The system has a defined behaviour. When something breaks, there is a documented list of what might have caused it and how to fix it. The support team does not need to understand how the system was built - they need to know how to operate it.
Bespoke software has no such documentation. When a bug appears in a custom system, the path to fixing it runs directly through understanding the original design. Why was this field structured this way? What does this integration depend on? What assumption about the business process does this code make, and has that assumption changed?
Without that understanding, support becomes investigation. The investigation takes time - time during which the system is degraded or down, and the business is not moving. The support team is starting from scratch every time something needs attention.
There is also the change request problem. Bespoke systems need ongoing development - not because they break, but because businesses change. Adding a feature to a bespoke system requires understanding the existing architecture well enough to extend it cleanly. A developer who was not involved in the original build will find that orientation work takes significant time before any new development can begin.
What a proper SLA for bespoke software should cover.
A well-structured SLA for a custom system covers four things: response expectations, development capacity, monitoring and alerting, and escalation.
Response expectations define how quickly issues will be acknowledged and addressed - not just acknowledged. For a system that is central to business operations, the difference between a two-hour and a twenty-four-hour resolution is significant. The SLA needs to define what counts as a critical issue, what counts as a standard issue, and what the response commitment is for each.
Development capacity means there is an agreed allocation of development time available each month for maintenance, fixes, and minor enhancements. This prevents the common situation where a needed change requires a new scoping engagement, a proposal, and a waiting period - which is not appropriate for a system in active operation.
Monitoring and alerting means the system is watched, not just responded to when someone reports a problem. Proactive monitoring catches issues before they surface as user-facing failures - and it requires someone who knows what normal looks like for the specific system.
Escalation defines what happens when something exceeds the standard response capacity - a critical bug that requires extended development work, an integration that has failed and cannot be restored quickly, a data corruption issue that needs investigation and remediation.
The handover problem.
The most common SLA failure pattern for bespoke software is not a bug - it is a handover. The original development team is no longer available. The new team inherits a codebase they did not build, documentation that is incomplete, and a business that needs the system to keep working while the new team orients themselves.
The orientation period is not short. A well-written, well-documented codebase still requires significant time for a new team to understand before they can make changes safely. A codebase that was not written with future maintainability in mind requires even more - and the risk of introducing new problems while trying to fix existing ones is real.
The implication is that the best SLA support for a custom system is provided by the team that built it. They do not need to orient themselves - they are already oriented. They know why the decisions were made. They know what the system depends on and what it is sensitive to. The first fix from the original team takes hours; the same fix from a new team may take days.
We build with this in mind. Readable code, documented decisions, and dependency choices that do not create upgrade traps are not optional extras - they are what makes long-term support practical rather than heroic.
Who SLA support makes sense for.
SLA support makes sense for any SA business running operations on a custom system where downtime or degradation has a direct operational consequence. The system is not a reporting tool that could be unavailable for a day without impact - it is the platform the business runs on.
It makes most sense when the business wants one clear owner for the system: a team that knows it, is responsible for it, and can be reached directly when something needs attention. Not a helpdesk. Not a queue. Direct access to the people who built it.
What it is not is a fixed-scope retainer with a defined feature list. Every custom system has different needs. The SLA is scoped around those needs - what level of development capacity is appropriate, what monitoring makes sense for the specific system, what the response expectations should be for the specific operational consequences of an outage.
If you are running a custom system and want to understand what a proper SLA arrangement would cover, we can talk through it - no lengthy proposal before we understand your situation.
Start a conversation →