Custom Software Maintenance and Support

What 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 software maintenance, and 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, preventive). When that ratio flips, when most of the work is firefighting rather than forward movement, something structural needs attention.

Why the Builder Should Be the Maintainer

This is the argument no one else makes, and it is the single most important factor in long-term system health. The team that built your software holds something that cannot be documented, transferred in a handover meeting, or reconstructed from reading the code: accumulated context.

We have maintenance relationships that have lasted over fifteen years. We still look after systems we designed, built, and evolved across multiple business phases, team changes, and technology shifts. The reason is practical, not sentimental.

When the original builder maintains a system, they carry the full history of every architectural decision, every trade-off, every business rule that was encoded in response to a real situation. When a new team inherits unfamiliar code, weeks of archaeology precede any productive work. They read the codebase, guess at intent, miss edge cases that exist for reasons no documentation captures, and introduce regressions because they do not know what they do not know.

This is not an argument for vendor lock-in. It is an argument for value. You would not hand your accounts to a different accountant every year. You would not switch solicitors mid-case. The same logic applies to the people who maintain the system your business runs on. Continuity is not dependency. It is efficiency. Here is how we work with clients over the long term.

The Cost of Not Maintaining

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 takes a day to update. A system three versions behind takes 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 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 Maintenance Agreement Looks Like

Maintenance is not abstract. It is a defined set of activities that happen on a predictable schedule. Understanding what a typical month includes helps you evaluate whether you are getting value and whether your system is actually being looked after or just nominally "supported".

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

The commercial structure typically takes one of two forms. A monthly retainer gives you a predictable cost, guaranteed availability, and ensures proactive work actually happens. You are not competing for attention with other clients because your time is already allocated. Ad-hoc (pay-as-you-go) maintenance carries a lower commitment, but it is reactive by nature. You call when something needs doing, and you queue behind retainer clients. Neither model is inherently better. Some systems genuinely need very little ongoing work and ad-hoc makes sense. Systems that are business-critical or actively evolving benefit from the rhythm and predictability of a retainer.

Budgeting for Ongoing Maintenance

The industry standard for annual software maintenance sits at 15-20% of the original build cost. For a system that cost £50,000 to build, that is £7,500-10,000 per year, or roughly £625-835 per month. This is a planning figure, not a fixed rule, but it holds remarkably well across different system sizes and complexities.

Early years tend to run at the higher end of that range. The business is still learning what it actually needs from the system. Perfective work (new features, workflow refinements) is heavier as the gap between what was specified and what is truly useful becomes clear. This is normal and expected. It is not scope creep. It is the system and the business learning to fit each other.

Mature systems settle into a steadier rhythm. Adaptive and preventive work dominates. Feature requests slow as the system stabilises. The monthly cost becomes predictable and manageable. Planning for this long tail from the outset means no surprises. 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, Dependencies, and Keeping Current

Security maintenance causes the most anxiety, and for good reason. An unpatched vulnerability in a business system that holds customer data, financial records, or operational logic is a genuine risk. The good news is that staying current is straightforward when it is part of a routine, not an emergency response.

PHP has a defined support lifecycle. Each major version receives active support (bug fixes and security fixes) for two years, then security-only fixes for one additional year, then nothing. PHP 8.1, for example, stopped receiving security fixes in December 2025. If your system still runs on it, known vulnerabilities exist that will not be patched. Your application is exposed, and your hosting provider may eventually refuse to support it.

Dependency management follows the same logic. A typical Laravel application relies on dozens of Composer packages. Each one has its own release cycle, its own security advisories, its own breaking changes. Reviewing and updating these dependencies quarterly (at minimum) keeps the application secure and prevents the kind of version drift that turns a routine update into a major migration project. For a deeper look at how this works in practice, see our approach to security and operational maintenance.

Documentation and Knowledge Continuity

Good documentation covers architecture decisions, environment setup, deployment processes, and the business rules encoded in the system. 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.

That said, documentation is a supplement to accumulated context, not a replacement for it. No document captures every edge case, every implicit business rule, every reason a particular approach was chosen over the obvious alternative. This is what the industry calls "bus factor" risk: what happens if the person who knows the system is no longer available. Good documentation reduces that risk. A long-term maintenance relationship with the original builder reduces it further, because the knowledge is distributed across a team with years of shared context, not concentrated in a single document or a single person.

When to Maintain vs When to Rebuild

Properly maintained software 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. Here are the signs that point in each direction.

And the signs that maintenance is still the right path.

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 our approach to legacy system migration.

Choosing a Maintenance Partner

Price matters, but it is the least interesting factor in choosing who maintains your software. What matters more is whether the relationship will work over years, not just months. Here is what to look for, framed as outcomes rather than promises.

• ✓
  You own the code The source code is yours. You can take it elsewhere if the relationship ends. No lock-in, no hostage situations. Why owning your codebase matters.
• ✓
  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.
• ✓
  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.
• ✓
  Communication is clear and regular You receive monthly summaries of what was done and what is coming. No surprises, no invoices for unexplained work.
• ✓
  They will be there in a decade Track record matters. A maintenance partner who has been doing this for twenty years is a different proposition from one who started last year.

The best maintenance relationships are quiet. The system works. Updates happen. Security is current. The business owner does not need to think about it, and when they 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.

The Long View

Software maintenance is the majority of lifetime cost, and that is normal. It is not a problem to be minimised. It is the ongoing investment that turns a one-off build into a long-term business asset. The builder-maintainer relationship is the single biggest factor in whether that investment pays off. Proactive maintenance extends system life from 3-5 years to 10-15 years. Budget 15-20% of the build cost annually and plan for the long tail.

Your maintenance partner should be someone who knows the system, knows the business, and will still be around in a decade. We have been doing this since 2005. We still maintain systems we built in 2008. That continuity is not incidental to the quality of the work. It is the foundation of it.