Custom Software Maintenance and Support

What Custom Software Maintenance Actually Covers

The word "maintenance" covers a surprisingly wide range of work. Not all of it is fixing things that broke. In fact, most of it should not be. The industry recognises four distinct types of custom software maintenance. Understanding them helps you see what your money actually buys each month.

For a business running a custom Laravel application with a PostgreSQL database, here is what each type looks like in practice.

The balance between these four types tells you a lot about the health of your system and your maintenance relationship. A healthy ratio sits at roughly 20% reactive (corrective) and 80% proactive (adaptive, perfective, planned/preventive). When that ratio flips, when most of the work is firefighting rather than forward movement, something structural needs attention.

Is Your System Working, or Actually Maintained?

One of the most common misunderstandings is the belief that a system which appears to be working is the same as a system that is properly maintained. The two are very different. A system can run for years with no visible problems while quietly accumulating risk beneath the surface. This diagnostic helps you tell the difference.

Score your own system honestly. For each row, decide whether you sit in the left column or the right. If you do not know the answer, that itself is informative.

Why Continuity Matters in Maintenance

Whoever maintains your software needs context that goes beyond what any codebase or documentation can capture. They need to understand why the system works the way it does, not just how. This is true regardless of whether the maintainer is the original builder, an in-house team, or a new provider.

When a maintenance team has deep context on a system, whether accumulated through building it or through a long-term support relationship, the practical differences are significant.

This is not an argument for vendor lock-in. It is an argument for valuing continuity when you find a good maintenance relationship. If you do switch providers, invest properly in the handover. Budget time for the incoming team to shadow the outgoing one, walk through architectural decisions, and understand the business rules that are encoded in the code rather than written down anywhere. A rushed handover is one of the most common causes of expensive early mistakes.

The Cost of Neglecting Custom Software Maintenance

Unmaintained software does not stay the same. It degrades. Not because the code changes, but because everything around it does. PHP releases new versions. Laravel moves forward. Browsers update. Security vulnerabilities are discovered. Operating systems are patched. Your unmaintained application sits still while the ground shifts beneath it.

Technical debt is not linear. Each deferred update makes the next update harder. A system one PHP version behind typically takes a day to update. A system three versions behind can take weeks. A system five versions behind may require a rewrite of significant portions of the codebase. Here is what the pattern typically looks like.

Now contrast that with what a maintained system looks like at the same milestones.

The difference is not dramatic in any single month. It is cumulative over years. Maintained software typically lasts 10-15 years. Unmaintained software forces a rebuild at 3-5. That rebuild cost, which could have been avoided entirely, dwarfs what the ongoing maintenance would have totalled. Controlling your own platform risk starts with keeping the platform current.

What a Software Maintenance Agreement Should Include

A software maintenance agreement is not abstract. It is a defined set of activities that happen on a predictable schedule. Understanding what a typical month should include helps you evaluate whether a provider is delivering real value or whether your system is just nominally "supported".

Here is what a representative month of maintenance looks like for a custom web application.

Good maintenance requires specific tooling. Not every provider uses the same products, but the capabilities should be present regardless of brand names. Here is a baseline to check against.

Budgeting, Security, and Knowledge Continuity

A widely cited planning figure for annual custom software maintenance cost is 15-20% of the original build cost. It is not a fixed rule, but it holds well across different system sizes and complexities.

Early years tend to run at the higher end of that range as the gap between what was specified and what is truly useful becomes clear. Mature systems settle into a steadier rhythm where adaptive and preventive work dominates. When you are working through the total cost of ownership calculation, maintenance is the number that makes the five-year and ten-year projections honest. And when understanding the initial build investment, the maintenance budget is what puts that figure in its proper context.

Security is the area that causes the most anxiety, and rightly so. PHP has a defined support lifecycle: two years of active support (bug fixes and security fixes), then two years of security-only fixes, then nothing. Laravel follows a similar pattern: bug fixes for 18 months, security fixes for 2 years. Falling behind on either means running software with known, published vulnerabilities. Staying current is straightforward when it is part of a routine, not an emergency response. The same applies to Composer dependencies: reviewing and updating quarterly prevents the kind of version drift that turns a routine update into a major migration. For a deeper look, see how security and operational maintenance work in practice.

Documentation deserves the same discipline. Think about what a new developer would need if they had to pick up your system tomorrow: where the environment variables live, how the deployment process works, which business rules are encoded in the code rather than written down anywhere. Good documentation answers those questions. It should be maintained alongside the code, not written once during the build and forgotten. When documentation drifts from reality, it becomes worse than no documentation at all, because it misleads anyone who relies on it.

Retainer vs Ad-hoc: Choosing the Right Commercial Structure

The commercial structure of a maintenance agreement typically takes one of two forms, and each suits different situations.

Neither model is inherently better. Some systems genuinely need very little ongoing work and ad-hoc makes sense. But for anything business-critical or actively evolving, a retainer is the stronger choice. The rhythm and predictability keep the system moving forward rather than waiting for the next emergency.

A realistic service level agreement from a small, dedicated team looks different from enterprise support contracts. Here is what honest SLA tiers typically look like.

When to Maintain vs When to Rebuild

Properly maintained software typically lasts 10-15 years. That is a long time in business terms. But it is not forever. Some systems outlive their usefulness not because the code failed but because the business evolved beyond what the original architecture can accommodate. Recognising the difference between a system that needs maintenance and one that needs replacing is an important skill.

The decision to rebuild is not a failure of the software or the people who built it. It is a recognition that the business has changed enough to warrant a new foundation. Use this framework to think it through.

Signs that point towards rebuilding

Signs that maintenance is still the right path

The grey area: a structured way to decide

Most systems do not fall neatly into "maintain" or "rebuild". They sit somewhere in between, with some components working well and others causing friction. When you are in that grey area, score each dimension below on a scale of 1 (fine) to 5 (critical problem).

A phased migration, replacing the system piece by piece while the old one keeps running, is often less disruptive than a full rebuild. Either way, the decision should be deliberate, not forced by neglect. For systems that have crossed the line, see how legacy system migration works in practice.

Evaluating a Maintenance Provider

Choosing who maintains your software is a decision you will live with for years. Price matters, but it is the least interesting factor. What matters more is whether the relationship will work over the long term. Here is what to look for, and what to ask.

• ✓
  You own the code, unconditionally The source code is yours. You have access to the repository. You hold the credentials for hosting and third-party services. You can take everything elsewhere if the relationship ends. No lock-in, no hostage situations. Why owning your codebase matters.
• ✓
  They can describe their maintenance process in detail Ask what a typical month looks like. Ask about their tooling. If they cannot walk you through their security patching process, dependency management approach, and deployment pipeline, that tells you something.
• ✓
  Maintenance is proactive, not just reactive They find problems before you notice them. Dependencies are updated before they become urgent. Performance is monitored before users complain. Ask what proactive work they did last month for an existing client (without naming names).
• ✓
  They understand your business, not just your technology Maintenance decisions are better when the person making them understands why the system works the way it does, not just how. Look for curiosity about your business during initial conversations, not just technical questions.
• ✓
  Communication is clear and regular You receive monthly summaries of what was done and what is coming. No surprises, no invoices for unexplained work. Ask to see a sample maintenance report (redacted).
• ✓
  They have long-term client relationships Ask how long their longest maintenance relationship has lasted. A provider with multi-year client retention is demonstrating something that no sales pitch can replicate.
• ✓
  Their SLA promises are realistic Honest response times, clear coverage hours, no fictional 24/7 claims from a small team. Realistic SLAs are a sign of integrity, not weakness.

Red flags to watch for

The best maintenance relationships are quiet. The system works. Updates happen. Security is current. You do not need to think about it, and when you do need something, the response is fast because the context is already there. That quietness is not the absence of work. It is the presence of a well-run, long-term partnership.