How Do You Handle Ongoing Software Support?

Short Answer

Most agencies handle ongoing support through a monthly retainer that bundles hosting management, monitoring, patching, bug fixes, and a budget of hours for small improvements. A reasonable annual support budget is 15 to 25% of the original build cost, scaling with system complexity and uptime requirements. The retainer is not optional. Software that ships without an active support model starts decaying immediately as dependencies update, integrations change, and small issues compound. The shape of the agreement matters more than the price: a clear scope, a defined response time, and an honest model for what is and is not included.

What a Support Retainer Actually Covers

A useful support retainer covers five distinct things, and they are easy to confuse with each other.

Infrastructure management. Keeping the hosting, database, and underlying servers running, patched, and backed up. This is the closest thing to a fixed cost. The work happens whether you ask for it or not, and skipping it produces the biggest risks: security gaps, downtime, data loss. For how we handle the security side specifically, see How Do You Protect Our Data?

Monitoring and alerting. Watching uptime, response times, error rates, and security events. The system should detect problems before users do, and the team should be paged for serious ones. Without monitoring, you find out about outages from customer complaints.

Bug fixes. Issues found after launch that fall within the original scope. There is always a tail of bugs that surface in production with real users and real edge cases; a support retainer absorbs those without a separate quote each time.

Minor changes and improvements. A budget of hours for small additions: new fields, tweaks to workflows, content updates, report adjustments. This keeps the system evolving with the business without triggering a formal project every time something needs to change.

Larger feature work that exceeds the retainer’s hour budget should be priced as a separate engagement. A good support agreement names this distinction clearly so neither side is surprised.

Why Businesses Need This

Software that ships without ongoing support is software that quietly breaks. Dependencies update with breaking changes, third-party APIs are deprecated, security vulnerabilities are disclosed, and the operating system underneath all of it needs patches. In a year, an unsupported system might still work, but the gap between current best practice and what it actually does grows wider every month. By year two, even minor changes are painful because the dependencies are so old.

Beyond technical decay, there is the human reality of using software in a live business. New people join who need training. Existing processes evolve and the system needs to follow. Small frustrations accumulate and need addressing. A retainer gives you a relationship that absorbs this without each item turning into a small project. For what to expect in the period immediately after launch, see What Happens After Software Launches?

What to Look For

• A response time commitment, not just availability. “We respond within 4 hours during business hours; critical outages within 1 hour, 24/7” is a meaningful commitment. “We will get back to you when we can” is not.
• Clear separation between included and additional work. Hosting, monitoring, patching, and bug fixes inside the retainer; new features priced separately. The line should be defined in writing.
• Hours rollover, or a clear “use it or lose it” policy. Some months you will use nothing; some you will use double. The retainer should accommodate this honestly.
• Quarterly or annual review meetings. A 30-minute conversation every quarter on roadmap, performance, and emerging needs is far more valuable than another support ticket.
• Access to the same team that built the system, not a separate support desk. Continuity of knowledge is the entire value of a retainer.

Common Mistakes

The most common mistake is not having a retainer at all and assuming you can fall back on the agency ad hoc. In practice, ad hoc requests take longer (because the team has to context-switch), cost more (because each one is quoted separately), and are deprioritised behind active projects.

Choosing the cheapest retainer that does not include monitoring or patching is the second. Those are the most boring and the most important elements, and skipping them is where outages and breaches come from.

Treating support as adversarial is the third: counting hours obsessively rather than building a partnership. The relationship works best when both sides expect it to last years.

How We Approach This

We offer support retainers on every system we build, structured to include hosting, monitoring, patching, bug fixes, and a budget of hours for small improvements. The shape is tailored to the system: a low-traffic internal tool needs less than a customer-facing platform, and the scope is written down so both sides know what is included.

Plan for the Long Term

The support cost should be part of the conversation from the start of any new project. The Support Retainers page covers our retainer model and infrastructure operations in more depth. You can find related reading in the Knowledge Center.