What a Laravel Support Retainer Actually Covers

You already know your Laravel application needs professional support. Maybe your developer left — we've written about what happens when that occurs. Maybe you've seen the security consequences of nobody applying updates. Maybe you've noticed the warning signs and looked up what rescue actually costs.

The problem isn't motivation. It's that you can't find a straight answer about what you're actually buying.

I researched what 10 UK Laravel agencies publish about their retainers. The answer, overwhelmingly, is not much. Only three publish pricing on their website. The rest hide behind "get in touch" — which means you're committing to a sales conversation before you even know whether the numbers work.

This article fixes that.

What "support" actually means — and what it doesn't

The word "support" covers a wide range of work, and agencies use it loosely. Before you evaluate any retainer, it helps to understand the four categories of maintenance work that exist for any software application. This isn't a framework I invented — it comes from ITIL (the standard used across IT service management) — but almost no web agency explains it to clients.

Corrective maintenance is bug fixes. Something breaks, you report it, someone fixes it. This is the baseline. Every retainer in the UK market includes this. If a retainer doesn't explicitly cover bug fixes on your existing application, it isn't a support retainer — it's a hosting plan with a markup.

Adaptive maintenance keeps your application compatible with the world around it. Browsers update. Operating systems change. Third-party APIs deprecate endpoints. PHP releases new versions. Laravel releases new versions. Your application has 30–80 Composer dependencies, each with its own release cycle. Adaptive work ensures all of this keeps working together. Security patches fall into this category — and they're arguably the most important line item in any retainer.

Preventive maintenance is the work most agencies skip unless you're paying for it. Refactoring fragile code. Improving database query performance. Adding documentation so the next person doesn't start from scratch. Reducing the technical debt that makes every future change slower and riskier. A good retainer includes preventive work as standard. We include progressive technical debt reduction in every plan — even quiet months should make your application a little better, not just a little older.

New features — anything that adds functionality that doesn't currently exist — sit outside all four categories. This is the boundary that causes most disputes between clients and agencies, and it's worth understanding precisely.

The practical boundary most agencies use is an hours threshold, and it's worth asking about explicitly before you sign. We publish ours on the pricing page: tasks under 1–2 hours are handled within the retainer, tasks at 2–4 hours are flagged, and anything over 4 hours is quoted separately.

Response times: what the words actually mean

This is where the gap between marketing copy and contractual reality is widest.

A critical distinction that most agencies gloss over: response time and resolution time are different things. A response commitment means someone has acknowledged your issue and is looking at it. A resolution commitment means it's fixed. Almost every agency in the UK commits to the former and avoids the latter — and with good reason. ContractNerds (a UK legal advisory specialising in SaaS and agency contracts) explicitly advises against committing to resolution times because resolution depends on issue complexity, not just team speed.

The IT industry standard uses four severity levels. P1 (complete outage) typically gets a 15-minute response. P2 (major feature broken) gets 30 minutes. P3 (minor bug) gets an hour. P4 (enhancement request) gets 4 business hours. These are aspirational benchmarks from dedicated IT support providers. Most web agencies are far less aggressive — the most specific published commitment I found across 10 UK Laravel agencies was same-day acknowledgement with 24–72 hour resolution depending on severity.

The questions that matter before signing: Does the agency define severity levels in writing? Do they commit to response times per severity level? Is that commitment in the contract, or just on the website? Is out-of-hours coverage included, or does it cost extra?

Our own commitments scale with the plan: next-business-day on Professional (£450+VAT), same-day for urgent issues on Business (£750+VAT), 4-hour response for critical issues on Enterprise (£1,250+VAT). "Critical" means site down or security breach — not "I'd like this by Friday." We publish these on the pricing page because you shouldn't need a sales call to find out whether the SLA matches your needs.

How hours work — and why the model matters more than the number

The UK market uses several models for structuring retainer hours. Fixed hour banks give you a set number per month — typically 5–30 hours — with overages billed at an hourly rate. Fair-use models skip the hour count entirely and cover an agreed scope of work. Pay-as-you-go gives flexibility but zero priority. Hybrid models charge a base fee for availability plus tracked hours for work.

Each has trade-offs. Fair-use sounds generous but makes scope disputes harder to resolve without a defined boundary. Pay-as-you-go means you're in the same queue as everyone else. The hour bank model can lead to clock-watching — but it's the most transparent, and transparency is worth more than the illusion of unlimited support.

We use a fixed hour bank because it's the clearest: you know exactly what you're buying, and we track every hour against it. Our four tiers — 6, 10, 20, and 30+ hours — are designed for different levels of need, from stable applications that just need reliable backup to complex platforms that need near-dedicated support.

Rollover is worth asking about specifically. The most common model across the market is use-it-or-lose-it. We use a tiered policy: Professional hours don't roll over, Business rolls up to 2 hours, Enterprise and Premium get full rollover with a cap. The logic is straightforward — the more you commit, the more flexibility you get.

Overages in the UK typically revert to the standard hourly rate without a premium surcharge, which is notably different from US practice where 15–20% surcharges are common. Our overage rates are £70–£85/hour depending on the tier, communicated before any charges apply.

Where the money actually goes

This is the section most retainer articles skip — because it makes the ad-hoc alternative look bad.

When you hire a freelancer for a one-off engagement, the headline rate is £375–£500 per day for a competent UK-based mid-to-senior Laravel developer (IT Jobs Watch median: £350/day). That sounds reasonable. The problem is everything around the headline rate.

A freelancer engaging with an unfamiliar codebase needs 2–5 days minimum to understand the architecture, the database schema, the deployment pipeline, and the coding conventions before producing meaningful work. Research from CodeInterview puts the broader figure at 1–3 months to reach independent medium-feature delivery on an existing codebase. Prosum's 2026 data suggests new developers operate at 20–50% output during ramp-up.

Every time you engage a new freelancer, you pay that onboarding cost again. Every time they finish and move on, their knowledge of your system leaves with them. Devsu's research found that organisations lose 42% of project-specific knowledge when developer turnover exceeds 20% per year.

The result: on an ad-hoc model, roughly 43p of every £1 you spend goes to productive work. The rest goes to finding, vetting, briefing, onboarding, reviewing, and fixing the gaps left by someone who doesn't know your system. On a retainer with a team that already knows the codebase, that figure is closer to 74p.

The hidden cost — the one that doesn't appear on any invoice — is continuity. A retainer developer who has spent six months learning your application spots problems a freelancer seeing the codebase for the first time would miss entirely. They know where the technical debt lives. They know which parts of the system are fragile. They know the deployment pipeline's quirks. That institutional knowledge compounds over time — and it evaporates every time you switch to a new freelancer.

What the UK market actually charges

Transparency is rare. Of 10 UK agencies I researched, only three publish pricing. That opacity tells you something — agencies that don't publish pricing are typically not at the lower end.

The UK market ranges from £50–£80/hour pay-as-you-go (no priority, no commitment) through fixed hour bank retainers at £475–£1,900/month, up to £10,000/month for scope-based retainers from official Laravel Partners offering full team access. The G-Cloud government framework — the only public-sector benchmark — prices Laravel support at £550–£1,900/month.

For context: custom software maintenance typically costs 15–25% of the original build annually. A Laravel application that cost £50,000 to build requires £625–£1,042/month to maintain properly. WordPress support for a far simpler technology stack runs £295–£695/month. Shopify retainers start at £425/month for a managed platform where the vendor handles hosting and security — your retainer only covers the storefront code.

A Laravel application is bespoke software running on infrastructure you're responsible for. The retainer covers everything a managed platform handles for free (security, hosting, patching) plus everything a managed platform can't do (your custom business logic, your integrations, your specific architecture).

Our plans start at £450+VAT/month for 6 hours with next-business-day response, scaling to 30+ hours with near-immediate response at the top end. Three-month initial term, then rolling monthly with 30 days' notice. Full details on the pricing page.

What to ask before you sign — with any agency

You now have enough context to evaluate any retainer proposal — ours included. These are the questions that separate a professional support arrangement from a gentleman's agreement.

On scope: What's explicitly included? What's explicitly excluded? Where's the boundary between maintenance and development — is it defined by hours, by task type, or by something else? Is that boundary written into the contract, or is it just implied?

On hours: How many hours are included? Do unused hours roll over? What's the overage rate — and is it communicated before charges apply? Is there a fair-use cap?

On response times: What severity levels do you define? What's the response time per level — and is that a response time or a resolution time? Is that commitment contractual? Is out-of-hours coverage included?

On continuity: Who actually works on your application? Is it the same person each month, or a rotating pool? What happens if that person leaves? How is knowledge about your codebase documented?

On commitment and exit: What's the minimum term? What's the notice period? What documentation do you receive if you leave? Do you own the work produced during the retainer?

None of these questions are unreasonable. For our part: three-month initial term, rolling monthly after that, 30 days' notice to cancel. Published pricing, published scope, published exclusions. We want clients who stay because the service is valuable, not because they're locked in.

What this means for your decision

If you've read this far, you're past the "do I need support?" question. The earlier articles in this series — on developer departures, security neglect, liability signs, and rescue costs — covered that ground.

The question now is what kind of support, from whom, and at what price. You now know what's typically included, where the scope boundaries sit, how response times actually work, why the ad-hoc model costs more than it appears, and what the UK market charges.

What should not be part of the equation is mystery. You should know all of this before you speak to anyone.

Now you do.