"The system was delivered successfully and operated smoothly for a while. But six months later, it suddenly went down with an error. When we contacted the development agency, they said, 'Since there is no maintenance agreement in place, we'll need to quote this separately,' and fixing it took several days. In the meantime, business operations were completely halted"—we heard this story from an administrator whose company outsourced business system development. A system does not end when it is built and handed over. The budget and operational framework required to run it safely post-launch are essential separate commitments. If this is omitted during initial procurement, you only realize nothing was decided when trouble strikes.
When procuring a website or business system, attention naturally gravitates toward "how much it costs and when it will be finished." However, equally crucial is "who takes care of it, and to what extent, once it goes live." In this article, we outline the key items clients should verify in maintenance and operations contracts.
What "maintenance" covers varies by company
The first thing to understand is that what a "maintenance contract" encompasses varies drastically from one development agency to another. For one company, maintenance may strictly mean "fixing critical bugs," while for another, it includes "monitoring, backups, and minor modifications." Even if a contract simply states "Monthly maintenance: ¥XX,000," without reviewing the details, you cannot know what is included and what incurs extra fees.
As a client, your first priority is confirming how the following four points are handled.
| What to verify | What happens if omitted |
|---|---|
| To what extent bug fixes are covered free of charge | Unexpected expenses when told "That's by design, so it costs extra" |
| Who handles security updates | Vulnerabilities left unpatched, inviting hijacking and data breaches |
| How quickly incidents are addressed | Operations stall while hearing "We can respond in a few days" |
| Whether minor modifications are included or quoted separately | Waiting for quotes on every minor change |
Security updates are particularly prone to being overlooked. Systems begin aging the moment they are built, with new vulnerabilities continually discovered in underlying components. An unpatched system grows increasingly hazardous over time. This dynamic—where software becomes vulnerable unless continually maintained post-release—is examined thoroughly in our article on viewing technical debt as a business risk.
Quantify "by when issues will be addressed"
During an outage, the most stressful situation is not knowing when systems will recover. The remedy is an agreement that commits to response times and service quality with clear metrics—commonly known as an SLA (Service Level Agreement). You do not need to overcomplicate it; simply establish concrete numbers at signing, such as "initial response within X hours of notification" and "maximum permissible monthly downtime."
Naturally, faster and more extensive support raises costs. A 24/7/365 immediate-response setup may be excessive for many small and medium-sized business systems. The key is determining required service levels by working backward from how many hours of downtime your business can tolerate. Delegating this decision entirely to the vendor often results in either overpaying for maintenance or facing operational paralysis from inadequate coverage.
Avoid situations where "only that agency can fix it"
Another vital consideration in maintenance agreements is preventing vendor lock-in where no other company can touch the code. If communication with your current vendor breaks down or rates suddenly escalate, you will be trapped unless the system can be handed over to a third party. To safeguard against this, verify during maintenance negotiations that system architecture and configurations are documented, and ensure administrative credentials remain under your organization's ownership.
The principle of maintaining hand-off readiness is discussed in our guide on how to procure software without vendor lock-in. Similar pitfalls happen with websites, where taking over websites after losing contact with the original creator is a classic failure case. Remember: maintenance contracts exist to ensure worry-free ongoing operations, not to lock your company in.
Include "ongoing operational costs" in procurement estimates
System costs extend far beyond initial development fees. Running the software post-launch requires ongoing monthly expenses. If these are omitted from initial budgets, unanticipated costs will steadily accumulate after rollout. During procurement, request proposals that present initial development costs alongside ongoing monthly maintenance and operations fees, and confirm precisely what services that maintenance covers.
"Our maintenance terms are vague and we don't know what incurs extra fees," "We haven't agreed on response times for outages," or "We worry whether anyone other than our current agency can maintain the system"—if you share these concerns, feel free to reach out to GleamHub's system development and operations support. We will help you establish an operational foundation from the procurement phase so your system never ends with mere delivery.
