Signs Your Laravel Application Is Becoming a Liability

Peer-reviewed studies from Chalmers University tracked hundreds of developers over months of daily work and found that technical debt — the accumulated cost of shortcuts, deferred updates, and undocumented decisions — wastes between 23% and 36% of all development time (Besker, Martini & Bosch, ICSE 2018; Journal of Systems and Software, 2019). Not on features. Not on fixing bugs. On navigating problems created by earlier neglect. Stripe's research, which included UK developers, put the figure at 42% (Stripe Developer Coefficient, September 2018).

That is not a rounding error. It is nearly half of every pound you spend on development, lost to servicing debt you may not even know you carry.

This article is a self-diagnosis checklist. Seven warning signs, each backed by published data, each with a practical way to check whether it applies to your application. Two of the seven — developer departure and unpatched security — are covered in depth in earlier pieces (What Happens When Your Laravel Developer Leaves and Laravel Security: What Happens When Nobody's Applying Updates). This piece covers the broader picture: the signs that individually seem manageable but collectively indicate an application that has crossed from asset to liability.

1. Your PHP or Laravel version is no longer supported

This is the most objective test on the list. Either your software receives security patches, or it does not. There is no grey area.

As of March 2026, only PHP 8.4 and 8.5 receive active support (php.net/supported-versions). PHP 8.2 and 8.3 receive security fixes only — and 8.2's security window closes in December. Everything else is end-of-life. W3Techs, the industry standard for server-side technology tracking, shows that at least 43% of all PHP websites run completely unsupported versions (W3Techs, March 2026). Packagist data from active developer environments puts 26.6% on unsupported PHP (stitcher.io, June 2025) — and that represents the better end of the spectrum, because it measures projects someone is still actively working on.

Laravel's lifecycle is more aggressive still. Only the current major version receives patches of any kind (laravel.com/docs/releases). Laravel 12 — released 24 February 2025 — is the only supported version today. Laravel 11's security support ended five days ago, on 12 March 2026. Everything from Laravel 10 downwards has been end-of-life for months or years.

No public source provides a precise breakdown of live Laravel applications by version, but the State of Laravel 2024 community survey (4,090 respondents) found over 25% of respondents still using PHP 7.4, and nearly 4% still on PHP 5. Given typical adoption lag, an estimated 40–60% of production Laravel applications are running end-of-life framework versions. That is an informed estimate, not a directly measured figure — but the direction is not in doubt.

How to check. Open your composer.json file and look for the php requirement and the laravel/framework version. Compare both against the support tables on php.net and laravel.com. If either shows end-of-life, your application receives zero patches for any vulnerability discovered from this point forward.

We covered the specific CVEs and exploitation timelines in detail in Laravel Security: What Happens When Nobody's Applying Updates. The short version: PHP averages 15–18 new vulnerabilities per year, attackers begin scanning for them within hours of disclosure, and the ICO has fined multiple UK organisations specifically for leaving known vulnerabilities unpatched.

2. Nobody fully understands the codebase

We wrote a detailed piece on what happens when your Laravel developer leaves — the knowledge gap, the replacement cost, the seven-month productivity cliff. If that scenario applies to you, read it here.

But the problem is not limited to departures. Many applications are nominally supported by the person who built them, yet that person's understanding has degraded over time. A developer who built your application three years ago and has since taken on other clients may not remember the architectural decisions they made, the workarounds they introduced, or the dependency they pinned to a specific version because the next one broke something. They have their own technical debt — in their memory.

The academic research on this is unambiguous. A study of 133 software projects found that 65% had a bus factor of two or less, and 46% had a bus factor of exactly one (Avelino et al., ICPC 2016). For a custom business application, the bus factor is almost always one: one person, one head, one resignation away from a crisis.

GitLab's 2025 developer survey found that 44% of organisations say onboarding a new developer takes more than two months. For a poorly documented legacy codebase — which describes the majority of bespoke Laravel applications built by solo developers or small agencies — practitioners consistently estimate six to twelve months before genuine productivity. And the UK talent pool for this specific skill set is not large: IT Jobs Watch recorded just 37 permanent PHP Laravel developer vacancies in the six months to March 2026, with a median salary of £55,000.

How to check. Three questions. Can someone other than the original developer deploy a fix to production within 24 hours if something breaks tonight? Is there written documentation — not code comments, but actual documentation — explaining how the application works, how it is deployed, and where the credentials live? Do you hold all source code, server access, and domain registrations directly, or does a third party control any of them?

If any answer is no, your application has a knowledge-dependency problem that is getting worse with every month that passes.

3. Your dependencies are rotting

A fresh Laravel installation pulls in approximately 70 Composer packages from just six direct dependencies. A production application easily reaches 100–200 Composer packages plus an npm dependency tree for the frontend. Each package is maintained by someone — and the evidence on how long "someone" keeps maintaining things is sobering.

Sonatype's analysis of over seven million open source projects found that 18.6% of projects maintained in 2022 became unmaintained by 2023 (Sonatype, State of the Software Supply Chain, 2023). Academic research tracking project survival across multiple ecosystems — including Laravel specifically — found that over half of all open source projects become inactive within four years.

This matters because dependencies are the largest source of vulnerabilities in any modern web application. The Synopsys OSSRA 2024 report audited 1,067 commercial codebases and found that 84% contained at least one open source vulnerability. 74% contained high-risk vulnerabilities — up from 48% just two years earlier. 91% contained components more than ten versions out of date.

The compounding factor is transitive dependencies: packages your developer never chose, pulled in automatically as dependencies of dependencies. Research from Endor Labs found that 95% of all vulnerable dependencies are transitive (Endor Labs, State of Dependency Management, 2022). Your developer may not know they exist. Even the latest version of a package has a 32% chance of containing a known vulnerability.

The PHP ecosystem has a specific concentration problem. A June 2025 academic study analysing over 31,000 vulnerability reports found that PHP packages average 4.92 vulnerabilities per vulnerable package — nearly three times the concentration of npm or Go (arXiv:2506.12995, June 2025). When a critical PHP package is vulnerable, the blast radius is proportionally larger.

How to check. Ask your developer to run composer audit and npm audit. These commands check every installed package against known vulnerability databases. The output will list any packages with active security advisories. If the list is long — or if nobody is available to run the commands — that is the answer.

4. Your bug backlog is growing faster than you can close it

A growing bug backlog is not a sign that your developer is underperforming. It is a sign that the codebase has accumulated enough debt that fixing one thing risks breaking another, and every repair takes longer than it should.

The Chalmers University research quantified this precisely. In nearly a quarter of all encounters with existing technical debt, developers were forced to introduce additional technical debt — not by choice, but because the constraints created by earlier shortcuts left no clean path forward (Besker, Martini & Bosch, ICSE 2018). Martini and Bosch, in a peer-reviewed study across nine sites at six international companies, demonstrated that architectural technical debt is "contagious," spreading through a codebase with what they described as potentially exponential compound interest (Martini & Bosch, Journal of Software: Evolution and Process, 2017).

McKinsey documented the business consequence. A B2B company they studied walked away from 25% of a $2 billion margin-expansion opportunity because tech debt made the implementation costs prohibitive. Two and a half years later, they had completed only half the planned work (McKinsey, "Breaking technical debt's vicious cycle," April 2023). Across their survey of 50 CIOs, 60% said their organisation's tech debt had risen perceptibly over the prior three years (McKinsey, "Tech debt: Reclaiming tech equity," October 2020).

The pattern at SME scale is less dramatic but structurally identical. A feature request that took three days two years ago now takes three weeks. Your developer describes the code as "fragile" or "tightly coupled." Bugs reappear in areas that were supposedly fixed. Each symptom alone seems like a normal software problem. Together, they describe a codebase where the cost of every change is increasing.

How to check. If you use a project management tool or issue tracker, look at the trend line. Are bugs being closed faster than they are opened, or is the gap widening? If you do not have an issue tracker — if bugs are managed through email, Slack, or verbal reports — that absence of visibility is itself a warning sign.

5. Feature delivery has slowed and you cannot explain why

This is the sign non-technical founders feel most acutely. The application used to move fast. Now it does not. Nobody can quite explain why.

The explanation, almost always, is that the codebase is consuming its own capacity. Stripe found that developers spend 13.5 hours per week on technical debt and an additional 3.8 hours on "bad code" — 17.3 hours out of a 41.1-hour week (Stripe Developer Coefficient, September 2018). McKinsey found that 10–20% of new-product technology budget is diverted to resolving tech debt rather than building anything new (McKinsey, October 2020). That is money and time spent running to stand still.

The DORA programme at Google, which has surveyed over 39,000 professionals, provides the starkest comparison (DORA/Google Accelerate State of DevOps Report, 2019 and 2024). They classify software teams into four performance tiers, and the differences are not incremental — they are orders of magnitude apart. Elite-performing teams deploy code on demand, with a change failure rate of 5% and recovery measured in minutes. Low-performing teams — the ones carrying accumulated debt — deploy monthly at best, with a 40% change failure rate, and take a week to a month to recover from failures. The 2019 DORA research found elite performers deploy 46 times more frequently than low performers.

At SME scale, you are not comparing yourself against Google. But the underlying dynamic is the same. A well-maintained application responds to business needs quickly. A neglected one fights back against every change. The DORA data confirms what practitioners observe daily: the difference between a maintained and unmaintained system is not 10% or 20%. It is a different category of capability.

How to check. Think about the last three changes you requested. How long did each take from request to deployment? Has that timeline been lengthening? If your developer qualifies estimates with phrases like "it depends on what we find" or "we might need to refactor first," the codebase is imposing a tax on every new feature.

6. Your application runs but nobody is watching it

An application that appears to work is not necessarily healthy. Without monitoring, problems accumulate silently until they become visible to users — at which point the damage is already done.

Log files are the most common culprit in Laravel applications. Without rotation, a single laravel.log file can grow without limit. Documented cases include log files reaching 20GB in a single day and 41GB per PHP worker process from deleted-but-still-open file handles. A 2GB log file will crash PHP with an out-of-memory error. The failed_jobs table — where Laravel stores details of background tasks that did not complete — grows indefinitely unless explicitly pruned. One reported case reached 12GB.

Database performance degrades predictably with scale. Queries that perform well at 10,000 rows appear in slow-query logs at a million. Without periodic index maintenance, MySQL's query optimiser chooses increasingly poor execution plans — one documented production case saw performance degrade 50 times over 30 hours in a write-heavy environment. A healthcare Laravel API was optimised from 27 seconds to under 100 milliseconds — a 287-fold improvement — simply by resolving query problems that had accumulated unnoticed.

The business impact of performance degradation is directly measurable. Google and Deloitte studied 37 brand websites across over 30 million user sessions and found that a 0.1-second improvement in mobile load time produced an 8.4% increase in retail conversions and a 9.2% increase in average order value (Google/Deloitte, "Milliseconds Make Millions," 2020). Performance is not a vanity metric. It is revenue.

How to check. Four questions. What is your application's average page load time? How many errors occurred in the last 30 days? When did someone last check disk space, memory, and database size? Is there an automated alert that notifies you if the application goes down? If you cannot answer any of these, you are driving without a dashboard.

7. You have no maintenance arrangement

This is the structural sign underneath all the others. An application without a maintenance arrangement is not being actively neglected — it is simply not being maintained. The distinction matters, because the cost difference between the two paths widens with every passing month.

Cross-industry research is remarkably consistent on the ratio. The BOMA Preventive Maintenance Guidebook puts reactive maintenance at 3–9 times the cost of planned preventive maintenance. The Marshall Institute says 2–5 times. De Sitter's Law of Fives, from civil engineering, states that if maintenance is not performed, repairs cost 5 times the maintenance cost — and if those repairs are also neglected, renewal costs reach 25 times the original. Stanford University's lifecycle analysis found deferred maintenance can cost up to 30 times the early intervention cost.

In software specifically, the Standish Group finds that post-deployment modifications typically cost 3–4 times the original development cost. UK agency data gives this a practical anchor: one agency reported an average emergency repair cost of £2,847 — equivalent to 19 months of their basic maintenance plan.

The comparison between a managed retainer and a full-time hire is covered in detail in What Happens When Your Laravel Developer Leaves. The headline figure: a £500/month retainer costs 7–8% of a full-time developer at £73,000 total employment cost. It eliminates recruitment fees, removes the 8–16 week hiring delay, and provides continuous codebase knowledge that no ad-hoc freelancer can replicate.

How to check. Is there a signed agreement — not an informal understanding, but a documented arrangement — specifying who is responsible for security patches, dependency updates, server monitoring, and emergency response? If the answer is "my developer will handle it when something comes up," that is not a maintenance arrangement. It is a hope.

The scorecard

Count how many of the following apply to your application.

One. PHP version is 8.1 or earlier, or Laravel version is 11 or below.

Two. The original developer is no longer actively involved.

Three. No written documentation exists beyond code comments.

Four. Your bug backlog is growing, not shrinking.

Five. Feature delivery has slowed noticeably over the past year.

Six. Nobody has run composer audit in the past six months.

Seven. There is no server monitoring or error alerting in place.

Eight. You do not hold all source code, credentials, and domain registrations directly.

Nine. The application has never had a security or dependency review.

Ten. There is no signed maintenance or support arrangement.

0–2 flags. Your application is in reasonable shape. Maintain what you have.

3–5 flags. The application is drifting toward liability. The problems are likely fixable with a structured maintenance plan, but the cost of that plan increases the longer it is deferred.

6–8 flags. The application is a liability. Technical debt is compounding, security exposure is accumulating, and a rescue project is becoming more likely — and more expensive — with every quarter that passes.

9–10 flags. This is an active business risk. You are exposed to security breach, regulatory action, and a rebuild costing tens of thousands of pounds. Treat it as urgent.

What to do with your score

If you scored three or above, three things are worth doing in the next 30 days.

First, establish the facts. A professional codebase assessment — not a sales conversation, but a structured technical review — will tell you exactly what version you are running, what vulnerabilities exist in your dependency tree, what the performance baseline looks like, and what it would cost to bring the application to a supported, secure state.

Second, secure your access. Confirm that you hold the source code repository, the production server credentials, the database backups, the domain registrations, and the DNS records. If any of these sit with a third party, get them transferred or at minimum documented. This is your business asset.

Third, establish ongoing maintenance. The data across every source cited in this article converges on the same conclusion: the gap between proactive and reactive cost is not marginal. It is 3–10 times, compounding annually, with regulatory and reputational penalties layered on top.

None of the seven signs in this checklist are unusual. They are the normal, predictable outcome of building a custom application and then treating it as finished. Software is never finished. It is either maintained or it decays. The only question is whether you address that on your terms — at a predictable monthly cost — or on the terms of the next security incident, the next developer departure, or the next ICO enforcement action.