What Is Laravel: What This Choice Means When You Commission a System

The “PHP 8.4, Laravel 13” written in a proposal is not a technical detail: those two lines decide how long the system will receive security patches, what will cost extra on it, and how expensive a handover to another developer will be.

The proposal arrives on a Friday afternoon, and in its technical section sit two lines nobody reads aloud in the meeting: “PHP 8.4” and “Laravel 13”. The price is clear, the deadline is clear, and those two lines look like the supplier’s own toolkit — about as important as which drill will make the hole in the wall, so they are usually skipped as a technical detail someone else is responsible for. The signature nevertheless sits under the whole document, and it is precisely those two lines that decide how long the system will receive security patches at all, what will generate a monthly invoice on top of the development price, and how expensive it will be, three years on, to hand the system to someone else.

This article is not about whether PHP is a good language and whether Laravel is a good framework, because developers settle that among themselves and the buyer gets no practical use out of that conversation. It is about four things a buyer can check in person and without technical knowledge: the support calendar, the licence, the labour market and the handover terms. All four are public, three of them are either dates or sums of money, the fourth is what can and cannot be known about the market, and none of them depends on how convincingly the proposal is written — which is why they are worth checking in the very week while the price can still be talked about.

What is Laravel, what is PHP, and why this is not one choice

PHP is the programming language the system’s server side is written in — the part that runs at the supplier’s or at your host’s and that the user never sees. Laravel, in turn, is a PHP framework: a codebase already written in the PHP language that solves what almost every project repeats — user sign-in, database queries, queues, file storage, sending email. In a proposal they stand side by side as one choice, but they are two separate products, maintained by two different teams with two different support calendars, and that is exactly why they are worth reading separately.

How widespread the language is turns out to be harder to say than you would expect. W3Techs, which regularly scans more than twenty million sites, wrote this August that PHP is used by 70.2% of all sites whose server-side programming language this tool knows. That last condition is the one that usually disappears when the figure is copied into a presentation: this is not 70% of every site in the world, but 70% of those this particular tool can recognise at all, and it itself describes part of that recognition as inferred indirectly — if the page is WordPress, then it is PHP.

A more useful figure for the buyer sits on the same page. Among the sites for which W3Techs also determines the PHP version, 63.3% run on the eighth, 28.7% on the seventh and 7.9% still on the fifth, even though the seventh version lost even security patches four years ago already. That means roughly a third of the measurable PHP internet today runs on code for which nobody is writing patches any more, and that did not happen because the language is bad or because someone made a mistake in development. It happened because nobody commissioned and paid for a version upgrade, and this is precisely the part of the risk a buyer can both see and manage.

The PHP support calendar is the first document worth opening

The PHP developers’ group’s rule is short and public: each version branch receives full support for two years from the first stable release, then two more years of security-only support for critical security patches, and after four years it reaches end of life altogether. In that rule there is one detail the retellings almost always cut off: the real end dates in the table are aligned to the last day of the year, not to the November anniversary of the release, so “two years from shipping” and what is written in the php.net table differ by a month or two.

In practice that means the following. Version 8.2 is currently on security-only support, and it reaches end of life at the end of this year, so in about four months. Version 8.3 lost full support at the end of last year and will receive security patches until the end of 2027, so for about another sixteen months. Version 8.4 stays in full support through the end of this year and then remains on security-only support for two more years, while the newest 8.5, which shipped last November, receives full support through all of next year and security patches until the end of 2029.

Version 8.1 reached end of life on the last day of last year, and this is the case worth attention if you already have a system rather than a proposal. If the supplier wrote it on 8.1 three years ago and nobody has changed anything since, then today it runs on a branch to which security patches no longer come, and neither the server, nor the browser, nor the system itself warns you. The page opens exactly as it did yesterday, clients notice nothing, and the only place you can see it is this same public table, which takes less time to open than it takes to read the proposal’s title page.

The Laravel calendar is shorter than the PHP calendar

Laravel states its policy even more briefly: bug fixes for eighteen months, security patches for two years, and a new major version every year around the first quarter. A long-term support release, which the industry calls LTS, no longer exists today — older versions really did have one, but this year’s table has no such column at all, so a proposal that writes “LTS Laravel” describes something nobody is selling at the moment. That is a shorter promise than many buyers expect from a framework on which a system for the next five years will be built.

In figures, according to Laravel’s own documentation, the order is as follows. Laravel 13 shipped this March, will receive bug fixes until the third quarter of next year, and security patches until 17 March 2028. Laravel 12’s bug-fix window closed in the middle of this August, that is, seventeen days before these lines were written, and its security patches will end next February. Laravel 11’s security support ended this spring, so a system that today runs on the eleventh version is already running without patches, however good it looks from the outside.

Notice that Laravel 13’s bug-fix end is given as a quarter, not as a specific date. That is an imprecision in Laravel’s own wording, and it is not a problem so long as it is copied exactly as it stands there; the problem starts the moment the supplier or the buyer rounds it to a particular day and then plans a budget from a number that is not in the source. One more boundary to know before a version is chosen: Laravel 13 requires at least PHP 8.3, so a system on the thirteenth version cannot be left on 8.2 even if 8.2 itself would still receive security patches for a while.

What both calendars together mean for a system you commission today

If the system is handed over on Laravel 13 together with PHP 8.4 or 8.5, then the first date on which something must move is March 2028, when Laravel’s security patches end, and that is about eighteen and a half months from today. PHP is not the constraint in this pairing, because both of those branches receive security patches for longer than the framework, so the first thing that ages is Laravel, not the language. That is also the only honest way to answer the question “how long will this system stand without further investment” — not with a feeling, but with the earlier of two public dates.

If the same system is handed over on Laravel 13 but PHP 8.3, the order reverses and the first deadline arrives in about sixteen months, when this PHP branch’s security patches end. If the supplier writes on Laravel 12, which for an existing project is still a perfectly normal choice, then security patches end next February, and a new system’s life starts with six months until the first mandatory version upgrade. The difference between the first and the third option is a year you can earn in one conversation before the contract, and that you can no longer buy after the signature.

Two mistakes in this arithmetic are so common that they are worth naming separately. The first is to confuse full support with security-only support, so on hearing that “PHP 8.4 support ends at the end of the year” it is worth asking which of the two windows is meant: ordinary bug fixing ends, but security patches still come for two more years. The second is to believe Laravel’s own sentence that a move to a new major version usually takes a day or less; that is a goal the developers have written down, not a measured average, and it cannot be entered in a contract as a deadline.

The licence costs nothing, and that is only true of the language and the framework

The Laravel framework is distributed under the MIT licence, which is one of the simplest open-source licences and lets the code be used, changed and sold on, asking only that the copyright notice be kept. With PHP it is a little more complicated, and that complication is live right now, because the licence is changing: versions up to and including 8.5 ship under revision 3.01 of the PHP licence, but from 8.6 they move to the fourth revision, which php.net itself describes as a “Modified BSD” licence and which in practice matches BSD-3-Clause. None of these variants provides for a fee.

That means that for the language itself and the framework itself the company pays neither per user, nor per processor core, nor per year, and this zero is not a promotion that will one day end. A useful comparison is the model Microsoft SQL Server uses: there it is licensed either by cores or by server together with client access licences, the Standard edition is limited to the smaller of four processor sockets or twenty-four cores, and the free Express edition — to one socket or four cores. We do not write exact sums here, because the price list changes and it has to be read at Microsoft; what is comparable for the buyer is the model, not the figure — one product bills by the volume of hardware, the other does not bill at all.

In a procurement this has two consequences worth writing down at once. The first is pleasant: there is no licence audit, no annual recalculation for users who have grown over the year, and no situation in which the software vendor arrives after three years with an invoice for a limit exceeded. The second is the one people tend to forget: open source removes dependence on the owner of the framework, but it does not remove dependence altogether. The dependence moves to other places — to the agency that alone knows how the project is put together, to the paid products that stand beside the code, to an abandoned package that nobody maintains any more, and to a major version whose support has ended. Those four places are the ones the buyer has to check, because the licence line says nothing about them.

Where Laravel starts to cost money: products that are not the framework

The same team that maintains Laravel also sells several products, and in a proposal they tend to stand on one line with the framework, as if they were part of it. Laravel itself separates the two things on its website: the packages — Laravel Horizon, Telescope, Pulse, Scout, Sanctum, Octane and others — are MIT-licensed and free, while the products are Cloud, Forge, Nightwatch, Vapor and Nova, and they cost money every month or every year. Envoyer is still sold separately. None of these products is needed for a Laravel system to run, and that is exactly why their presence in a proposal is a choice, not a necessity.

Prices this August looked as follows. Forge, which is used to manage servers, costs $12, $19 or $39 a month depending on the plan. Nova, which is an administration panel, costs $99 once for one project together with a year of updates and $79 a year to continue the updates, while the unlimited licence costs $299 and $249 respectively, and it covers your own projects, not your clients’ projects. Nightwatch, which collects system events, starts with a free plan and climbs to $20, $60 and $300 a month, plus a surcharge for events above the included limit. Laravel Cloud starts at $5 a month plus usage, and Envoyer costs from $10 to $50 a month.

The question for the buyer is not whether these products are good, because they usually are good and they save the developer several days a month. The question is which of them are included in the named price, on which account they are registered, and what happens to them if you change supplier in two years. A subscription that sits on the agency’s account and is not mentioned in the contract is precisely the dependence the MIT licence does not remove, because MIT talks about the code, not about the account in which it is deployed and watched.

What happens if the developer disappears

“Any Laravel developer can take the code over” is a sentence that is legally true and practically incomplete, and we have written it ourselves as well. The MIT licence really does let another company work with this code, without asking permission from us or from the Laravel team. Whether the new developer will be useful in the first week is decided by four quite different things, and all four can be checked before the contract is signed at all.

The first is the major version. A handover from Laravel 11 to a new team is not a handover but a version-upgrade project, because security support there has already ended and the first work will be not new functionality but the overdue upgrade to a supported release. The second is the distance from the framework’s convention: Laravel’s documentation assumes a particular layout of folders and classes, and the further the project has gone from that, the more expensive the familiarisation. There is no figure here and there is none in any source — there is only a direction; what the buyer can ask quite specifically is what in the project is written against the default and what need required it.

The third is the dependencies, that is, the third-party packages the system relies on. Composer, which manages them in the Laravel world, keeps a file of exact versions, and that file is valuable precisely because a new developer can install exactly what the previous one saw, not whatever is newest today. What this file does not guarantee is two things: that the package will still be available to download, and that no vulnerability has been found in it since. The command composer audit shows both in one invocation, and that is the shortest form of question you can ask at all about a third-party codebase.

The fourth is an abandoned package, and here the words mislead. Packagist, Composer’s public catalogue, marks that the maintainers have stopped, but that does not mean the package disappears or stops working: swiftmailer is still being issued, it has 449 million registered installations, the last release is from 2021, and at the same time it has three known vulnerabilities. In our own codebase for this site, which is Laravel 13 together with the Filament administration panel, there are 109 production packages and not one abandoned package — that is our figure for our project, not an industry average, because a published industry average exists nowhere.

How large the labour market is, and why nobody will give you an exact figure

To the question of whether it is easy to find a person who will take the system over, the honest answer is that public statistics on PHP or Laravel developers do not exist. There is indirect data, and it is valuable exactly to the extent that it is described precisely. In JetBrains’ PHP survey last year, among 1,720 people for whom PHP is the main language, 64% work with Laravel, 25% with WordPress and 23% with Symfony; the fieldwork was in the spring, the survey is biased towards users of JetBrains tools, which the company itself acknowledges, and the largest respondent groups come from Japan, the United States, Russia, China and France, not from the Baltics.

At European level Eurostat reported this May that last year 10.45 million information and communication technology specialists were working in the European Union, which is 5.0% of all employed people and 2.6% more than a year earlier. An earlier compilation from the same source has another figure, which is more useful to the buyer than the overall growth: in 2023, 9.55% of EU firms were looking or trying to hire such specialists, and among those that were looking, 57.5% could not fill the vacancy.

These figures are about specialists in the industry as a whole, not about PHP, and they must not be rewritten as a claim about the Laravel labour market — not by us, and not by a supplier who quotes them in your proposal. We ourselves have written on our service page that developers who take the work over are easy to find; preparing this article, we found no source for that claim, so we do not repeat it here. The practical sequence for the buyer is different in any case: not to believe in the size of the market, but to get the codebase into a shape a new person can enter cheaply regardless of how many such people there are.

Where we ourselves draw the line in a proposal

We have been building with Laravel since 2013, when its fourth version shipped, and that in practice means we have several times gone through exactly what this article warns about — a major-version upgrade that is not a day’s work and that cannot be done between other tasks. Our Laravel development page has a price and timelines, and that is a separate conversation; this article holds only what can be checked in a proposal regardless of who wrote it and how well it is written.

What we do not claim is that any developer takes over any codebase equally easily, because the previous section says the opposite. What we do claim is more specific and more checkable: the repository is the client’s from the first day, it holds the dependency file, the documentation and the deployment configuration, and at handover the version is the one that at that moment still receives security patches. If it seems to you that the choice is really between an off-the-shelf product and a commissioned system, then that is another conversation we have written separately, and if the question is specifically about an online store, then the WooCommerce and Laravel comparison answers more precisely than this article.

In practice the handover pack includes the repository with the full history, the dependency file with exact versions, a README with the steps to run it, the deployment configuration and access to every account the system runs in. That is what can be promised and checked. What cannot be promised is the market: how many people will take this work and at what price is not in our hands and is in no public statistic, so we do not answer this question with a convincing figure. The only thing that genuinely works in the buyer’s favour here is that the codebase is ordinary, the version is supported and the documentation is written at the time, not deferred to the week of handover.

What to ask before you sign

The first question is about dates: which Laravel major version and which PHP branch will be in the system on the day of handover, and when their security patches end. The answer is two dates, both can be checked on two public pages in five minutes, and they should be written into the contract or at least into the correspondence. If the supplier names a version whose support ends earlier than the warranty period, that is not forbidden and is sometimes even justified, but then both sides have to know it, and the price has to make clear who will pay for the upgrade.

The second question is about subscriptions: which paid products — Forge, Cloud, Nova, Nightwatch, Vapor or Envoyer — the system needs in order to run, how much they cost a month in total and on which account they are registered. The third is about the repository: from which day it is yours, whether it holds the dependency file, and whether the automatic check includes the composer audit command. The fourth is the money question that is usually postponed and then found in the budget as a surprise: who will pay for the major-version upgrade in a year and a half, and whether it sits inside the maintenance contract or will be a new commission.

None of these four questions requires you to understand the code, and none of them should be taken as distrust of the supplier. They are all about what will happen after the project is finished and the invoice is paid, and a good supplier answers them at once, because they know these dates by heart themselves. If the answer to any of them takes a week or turns into an explanation of why the question does not matter, then that is already an answer.

These four questions do not replace a technical assessment and do not answer whether the proposed architecture is good, but they remove most of the unpleasant surprises that usually arrive in the second or third year, when the original enthusiasm has ended and the system simply runs. If you have a proposal in hand and are not sure what the versions written in it mean for your timelines and your budget, write to us — an answer to these four questions can be prepared without opening the code.