Laravel Maintenance vs Development: What a Retainer Is For

Maintenance keeps what already exists working. Development builds what does not exist yet.

That sounds obvious until money is involved, at which point the line gets blurry fast. The good news is that the line is not something agencies invented to charge you twice. It is written into the international standard for software maintenance, and understanding it tells you exactly what a retainer is for.

What maintenance actually means

The international standard (ISO/IEC/IEEE 14764) recognises four kinds of maintenance, building on a model first set out by E. Burton Swanson in 1976.

Corrective maintenance repairs things that are broken: a VAT total that rounds the wrong way, a form that silently fails.

Adaptive maintenance keeps the application usable as the world around it changes. A PHP point release, a Laravel framework update, a deprecated Composer dependency, a payment provider that has altered its API.

Preventive maintenance heads off faults before they bite, through refactoring and reducing technical debt.

Perfective maintenance improves features that already exist, tightening a slow query or smoothing an awkward screen.

Here is the part that explains the confusion. Historically, enhancement has been the largest slice of maintenance work, not bug-fixing.

A survey of 487 organisations found that around 60% of maintenance effort went on perfective work rather than corrections (Lientz, Swanson and Tompkins, Communications of the ACM, 1978). Decades later, Robert Glass put it just as plainly: enhancement accounts for roughly 60% of maintenance cost and error correction around 17% (Glass, Facts and Fallacies of Software Engineering, 2003).

If most "maintenance" money has always gone on making software better rather than fixing it, no wonder people assume a new feature is simply more of the same.

But there is a ceiling on perfective work, and the standard draws it explicitly. ISO/IEC/IEEE 14764 defines a separate category, additive maintenance: modifying a product after delivery to add new functionality or features.

So the body that defines these terms treats building new functionality as a thing of its own. When a client asks whether a new feature is "just maintenance", the honest answer is that even the standard treats it as something else.

Where the line sits

The grey zone is real. Making an existing report load faster is perfective maintenance. Adding a report that did not exist is development.

The test is simple. Work that modifies existing functionality lives inside a retainer. Work that adds new functionality, with its own specification, design and testing, is a project. Every UK agency I reviewed draws the same line.

That is exactly how our Laravel Support retainer is scoped.

Inside your monthly hours you get bug fixes, security patches, Laravel and dependency updates, small tweaks, code review, documentation, performance checks, and progressive technical-debt reduction. That is the work that keeps an application secure and current rather than simply ageing.

New feature development, major Laravel version upgrades, third-party API integration changes, server or hosting migration, database restructuring, and performance audits beyond standard checks are scoped and quoted separately.

We are specific about this on the product page for a reason. A reader should know the boundary before the first call, not discover it on the third.

For the full breakdown of what sits inside the hours, we have written that up in what a Laravel support retainer actually covers. Major version upgrades in particular are a job with their own cost curve.

Why it is two commitments, not one

The deeper reason these are priced separately is about risk, not greed.

A retainer is a service agreement. It governs how well an ongoing service runs: response times, security kept current, the application improving month on month.

A build is a defined deliverable, a Statement of Work in procurement terms, with its own scope, timeline and acceptance criteria.

A fixed monthly fee is calculated against a bounded, predictable workload. Open-ended feature development is neither. Fold it into the fee and it does not just erode the maths. It displaces the maintenance you are paying for.

This is the trap. Feature requests are easy to wave through one at a time, and across a year they quietly eat the hours meant for updates and refactoring.

Scope creep is not a fringe problem. In a single year, 52% of projects ran into it, up from 43% five years earlier (PMI Pulse of the Profession, 2018). In a retainer it shows up as deferred patching and mounting technical debt, which is exactly how a maintained application starts behaving like a neglected one.

So we keep the two clean.

If you need extra hours, we tell you before any overage work begins and quote it at your tier's rate. Plenty of retainer clients run steady maintenance alongside the occasional project, and that works precisely because each is costed honestly.

And if what you need is a rebuild rather than upkeep, we will say so. That is a project, not a retainer, and taking your monthly fee for the wrong service helps nobody.

Setting the expectation

Set it cleanly and everything downstream gets easier.

A Laravel support retainer keeps your application secure, current, and a little better every month. New features are not off the table. They are quoted as the projects they are.

That clarity protects both the maintenance and the build. It is also the difference between a retainer that quietly decays and one that earns its place.