Most proposals for custom software spend 90 percent of their pages on the build phase and one paragraph on maintenance. This reflects how most buyers think about the investment: the big decision is "who will build it," not "who will keep it running." It is also backwards.

A well-built custom application typically costs as much to maintain over three to five years as it did to build. In some cases more. Yet this is the part of the engagement that buyers understand least, negotiate weakest, and discover the hard way once the software is live and their vendor has quietly moved on.

This article walks through what "maintenance" actually includes, what you should expect from a serious partner, and the questions worth asking before you sign anything.

What Maintenance Actually Covers

When a proposal says "maintenance included for 30 days" or "standard post-launch support," it is worth pausing to ask what that sentence actually means. Maintenance is not one activity; it is at least six, and they have very different cost and effort profiles.

1. Bug fixes

The most obvious category: something worked, now it does not, it needs to be fixed. The question buyers rarely ask is "fixed on what timeline?" A bug that blocks a user from logging in needs to be resolved within hours. A cosmetic issue can wait weeks. Without a defined SLA that distinguishes severity levels, you have no contractual basis to demand faster response when something goes seriously wrong.

2. Security patches

Every custom application depends on dozens, often hundreds, of third-party libraries. Those libraries release security patches regularly, sometimes urgently. Someone needs to monitor disclosure feeds, assess whether a vulnerability affects your system, test the patch, and deploy it. If nobody is doing this, you are running an increasingly insecure system without realising it. We have taken over applications where the core framework had not been updated in three years and several known vulnerabilities were exploitable from the public internet.

3. Dependency updates

Even without security issues, the ecosystem around your application moves. Frameworks release new versions, databases deprecate features, cloud providers retire APIs. Staying current is not optional; it is the price of keeping the software buildable and deployable. Defer these updates for two years and you face a much larger, much more expensive catch-up project.

4. Infrastructure and scaling

As your user base grows, your infrastructure needs change. Databases that were fine at 1,000 users start hitting limits at 100,000. Costs that were negligible in year one become significant in year three. Someone needs to watch performance metrics, tune queries, adjust capacity, and manage cloud spend. This is ongoing work, not a one-time setup.

5. Monitoring and incident response

Production applications fail in unexpected ways. Logs fill up, disks run out of space, integrations with external systems break when those systems change. You need someone watching the system 24/7, or at least during the hours your users rely on it, and you need a defined escalation path when something goes wrong at 2am. "We will check our email in the morning" is not a plan.

6. Small improvements and iteration

Users will find issues that are not bugs but are friction points. A field that should be optional. A report that needs a new filter. A workflow that is 20 percent slower than it could be. If there is no ongoing capacity for these improvements, your software ossifies, becomes harder to use, and eventually gets replaced. This is the category most maintenance contracts do not cover, and it is often where the real long-term value of a technology partner lives.

The SLA Terms That Actually Matter

Once you understand what maintenance includes, the contract terms that govern it start to matter in concrete ways. The key clauses to negotiate:

Response time by severity. Define at least three levels: critical (production down), high (major feature broken), standard (minor issue). Each needs a response commitment measured in hours or business days. A single "we respond within 48 hours" clause is not enough because it treats a full outage the same as a typo in a label.

Resolution time vs response time. Response means someone acknowledges the issue. Resolution means it is fixed. Contracts often commit to response times and stay vague on resolution, which lets a vendor acknowledge a critical bug within an hour and then take three weeks to actually fix it. Both commitments matter.

Coverage hours. Is support 24/7, business hours only, or something in between? If your users are in Europe but your vendor is on a different continent with no European team, you need to understand where the gaps are before a crisis exposes them.

Included vs billable work. Most maintenance contracts include bug fixes but treat new feature work as separate billable time. The line between "fixing a bug" and "making a small change" is often fuzzy, and some vendors use this fuzziness aggressively. A clear definition up front saves friction later.

Monthly capacity. Many maintenance retainers include a fixed number of hours per month. Understand how unused hours roll over (or do not), what happens when you exceed the cap, and whether the capacity can be pooled across multiple small issues.

Documentation and knowledge handover. What happens if you need to move to another vendor? A healthy contract includes commitments around documentation, handover procedures, and credential transfer. Without this, switching partners becomes prohibitively expensive, which is sometimes precisely why it is left vague.

The Hidden Cost Question: Who Owns What?

Beyond the SLA, the single most important question in a maintenance conversation is ownership. Specifically:

• Who owns the source code, and where is it hosted?
• Who owns the cloud accounts, databases, and DNS records?
• Who holds the credentials for third-party services (payment providers, email, analytics)?
• Who is named as the administrator on the domain registrar?

If the answer to any of these is "the vendor," you are dependent in a way that you may not realise. We have been called in to help clients whose previous vendor became unresponsive and held the entire production environment hostage, not deliberately, but because nobody had thought to transfer ownership and the person who set it up had left the company. Resolving these situations is painful, expensive, and entirely avoidable with the right contract language up front.

Long-Term Support as a Partnership, Not a Transaction

The proposals that treat maintenance as a brief addendum usually come from vendors who view the project as a one-time transaction. Build it, ship it, collect final payment, move to the next client. This model is not inherently wrong, but it creates a structural gap: the team that built the software is gone by the time it needs real ongoing work, and whoever takes over has to re-learn a codebase they did not write.

A partnership model looks different. The same team that built the software continues to maintain it, improve it, and evolve it over years. Institutional knowledge accumulates rather than evaporating. When a bug appears in month 18, the person fixing it was there when the original decision was made. When the business needs a new feature, the team already understands the architectural constraints and can estimate realistically.

At codelabs.rocks, our typical engagement runs 6+ months for the initial build and then continues, often for years, into ongoing development. This is not because we lock clients in. It is because once a team knows a codebase deeply, it is in the client's interest to keep working with them. The alternative, rotating vendors every 18 months, tends to produce worse software at higher cost.

Questions to Ask Before You Sign

If you are evaluating a proposal and the maintenance section looks thin, these questions will expose whether the vendor has thought seriously about the post-launch phase:

• What is your SLA structure, and how do severity levels map to response and resolution times?
• What hours is your support team available, and where are they based?
• How do you handle security patches and dependency updates? Is this included or billed separately?
• Who monitors production, and what tooling do you use? What happens during an out-of-hours incident?
• What documentation will exist at launch, and what happens to it if the engagement ends?
• If we ever needed to transition to another vendor, what does that process look like contractually?

Vendors who have lived through the post-launch phase of dozens of applications will have clear, specific answers. Vendors who have not will either deflect or promise things that sound good but are undefined in the contract. The difference is usually obvious within the first few questions.

The Bottom Line

Software is not finished at launch. It is barely started. The proposals that understand this, and that commit to specific support structures in writing, are the ones worth taking seriously. The proposals that treat maintenance as a footnote are the ones that generate the support tickets you will spend the next three years writing.

Before you sign for the build, make sure you know exactly what life looks like after launch. That conversation, held properly, changes how you evaluate every other part of the proposal.

‍

‍