Custom SaaS maintenance cost: build a budget you can verify

Start with the operations your business depends on. An outage during order entry has a different consequence from an internal report being unavailable until tomorrow. That difference helps establish coverage hours and recovery objectives before negotiating the monthly amount or choosing a support arrangement.

Divide the budget into infrastructure, recurring work and variable interventions. Infrastructure includes the resources actually billed under your architecture: compute, storage, backups or external service calls. Recurring work covers planned activities. Variable interventions depend on incidents, workload and requested changes.

Distinguish keeping the application operational from extending the product. Adding a pricing rule may constitute new scope even when the request arrives through the support channel. Define who classifies the request, how the business approves the estimate and whether reserved maintenance hours may be used for that work.

When planning a custom web application, request this breakdown before launch. Architectural decisions influence the work that will remain. A fragile integration or manual deployment process can require effort that the hosting price alone does not reveal, particularly when a small team must coordinate each release.

For updates, ask which components are monitored, who assesses urgency and how changes are validated. A list of installed versions helps, but should include the verification date and dependencies still awaiting attention. Agree on how an urgent security update outside normal coverage hours would be handled.

The Google SRE monitoring reference identifies latency, traffic, errors and saturation as useful signals. Your agreement must then specify who receives alerts and how quickly that person responds. Installing a dashboard does not create staffed coverage or establish an operational response commitment.

Backups require a different activity. The AWS Backup restore testing documentation describes periodic evaluations and monitoring their duration. In your budget, also reserve effort to verify that the recovered application can complete a business workflow, with the required records and connected services.

Keep the covered risk understandable to management: detecting an interruption, restoring order entry or preserving records. Connect each objective to an activity and evidence. List exclusions too, such as repairing an employee workstation or correcting information entered incorrectly by a user.

The following simulation is entirely fictional and uses Canadian dollars before tax. It is neither a Daillac quote nor a market average. The assumed labour rate is CAD 150 per hour, with no contractual minimum or on-call premium. Resource amounts and hours were selected solely to explain the calculation.

A normal month allows eight hours and CAD 450 for infrastructure: 8 × 150 + 450 = CAD 1,650. A busy month allows twelve hours and CAD 900 in resources: 12 × 150 + 900 = CAD 2,700. A month with an incident allows twenty hours and CAD 450 in resources: 20 × 150 + 450 = CAD 3,450.

These scenarios represent alternative months. The incident scenario’s twenty hours include recurring work; they are not added to the usual eight hours. An actual bill could include on-call, transfer, recovery or licence charges absent from this illustration. Replace every assumption with your suppliers’ applicable terms before making a financial decision.

For the busy month, identify the unit that grows: simultaneous users, retained files, outgoing messages, model calls or processing duration. Adding customers does not necessarily double every expense. Ask how resources scale and which limits can contain financial exposure, particularly when automated work can continue without someone watching it.

A CRM and ERP automation may add service calls, retries and connector monitoring. A provider’s API change can require adaptation even when your application has not changed. Specify whether this effort belongs in the recurring allowance and how interruptions caused by external providers are handled.

For a custom CRM or ERP, include the validation effort your own team contributes. A technically successful migration may still require reconciliation of orders or amounts. Internal effort belongs in the complete operating cost even when it never appears on the developer’s invoice.

The report should show planned spending, actual spending and the reasons for differences. For each intervention, request a task reference and concrete outcome: updated component, corrected error, completed exercise or revised procedure. An hours total alone does not help management understand the work that remains.

Include incidents with observed duration, impact and follow-up actions. For recovery work, distinguish the planned exercise, technical completion and business validation. If an exercise did not happen, the report should say so and propose a date. Recovery duration should only be presented as demonstrated when corresponding measurements exist.

Finish with deferred risks and decisions needed from the business. An ageing component may require a separate budget. Identify its owner, deadline and consequence of postponement. The monthly meeting can then authorize a specific action, establish the spending limit and agree on what will demonstrate completion.