Zend’s PHP Landscape Report found that 40% of PHP teams deploy at least one application on an end-of-life version of PHP – a version that no longer receives security patches from anyone. PHP is not a legacy curiosity in 2026. It still handles the server-side code of 70.5% of websites whose language can be identified, so those unpatched applications are running payroll, taking payments, and holding customer records right now. Anyone about to hire Laravel developers is buying into that landscape.
Supply is not the problem. Marketplaces list thousands of profiles, agencies publish landing pages promising vetted senior talent, and the framework has its own job board. The hard part of hiring Laravel developers is verification – separating the developer who keeps a codebase current from the one who will quietly add to that 40%. This guide covers what a Laravel developer should know in 2026, how to run a technical screen when you cannot read PHP yourself, and what each hiring route costs. We build and maintain Laravel applications for a living, so these are the checks we would want a client to run on us.
The Laravel skills worth checking in 2026
Laravel ships a major version every year around Q1, and the baseline for competent work moved in March. Three areas tell you most of what you need to know, and all three are visible from outside the code: how current the developer’s Laravel knowledge is, how they handle database access under load, and how they think about the frontend.
Laravel version currency as a first filter
Laravel’s support policy is published and unambiguous: bug fixes for 18 months, security fixes for two years. That turns any CV into a dateable document. Here is where the supported versions stand, straight from the official release notes:
- Laravel 13 – released 17 March 2026, requires PHP 8.3 to 8.5, security fixes until March 2028
- Laravel 12 – released February 2025, bug-fix window closing in August 2026, security fixes until February 2027
- Laravel 11 – security fixes ended 12 March 2026
- Laravel 10 and earlier – end of life
Only two release lines still receive security patches, and each carries its own PHP requirement: Laravel 13 refuses to run on anything below PHP 8.3. An upgrade therefore often means moving the runtime as well as the framework, which is where the cost usually hides. Our guide to PHP development covers the version landscape underneath.
If a developer’s most recent project ran on Laravel 9 or 10, they have spent over a year maintaining code that upstream abandoned. That is legitimate work, and it is different work from building on the current framework. So ask which version their last project used, and notice whether a number comes back at all. Vagueness here is the answer.
The follow-up question carries more weight: when did they last perform a major upgrade, and what broke? Laravel’s own documentation states that most applications can move to a new major release “in one day or less,” and that the team deliberately minimised breaking changes in 13. A developer who describes routine major upgrades as multi-week ordeals is either sitting on an unusually tangled codebase or has never run one. Both answers are useful to you.
Eloquent, queues, and the failures that surface under load
When a Laravel application falls over under real traffic, the cause is usually the way it talks to the database. The classic case is the N+1 query, and Laravel's own Eloquent documentation spells out the arithmetic: fetch 25 books and print each author's name without eager loading, and the framework runs 26 queries – one for the books, then one more per book. Multiply that by a listing page with pagination and a few relationships, and a page that felt instant on a developer's laptop with 30 rows starts timing out on 30,000.
Every Laravel developer knows the fix is with('author'). Far fewer have a system for catching the problem before a customer does. Listen for Model::preventLazyLoading(), called in AppServiceProvider and scoped to non-production environments: it makes Laravel throw a LazyLoadingViolationException the moment a lazy load happens in development or staging. The guard turns a silent performance bug into a failing test. Someone who has bothered to set it up got burned once and built a tripwire so it would not happen again.
Queues are the second place experience shows. Anything slow and non-urgent belongs off the request cycle: transactional email, PDF invoices, image processing, syncing with a payment provider or CRM. Laravel 13 added centralised queue routing through Queue::route(), so the wiring is easier than it used to be. Ask what the candidate moved to a queue on their last project and how they find out when a queued job fails. Specific answers – named jobs, a monitoring dashboard, a retry policy – mean they have run something in production. Queue theory in the abstract means they have read the docs.
The frontend decision: Livewire, Inertia, or a separate SPA
Laravel gives you three honest answers to the frontend question, and the official starter kits show which combinations the framework's own team supports:
- Livewire 4 with Flux UI – reactivity driven from the server, written in PHP. No separate frontend build, no second language. Suits form-heavy and admin-heavy applications where one team owns everything.
- Inertia 2 with React 19, Vue 3, or Svelte 5 – a single-page feel with Laravel still handling routing and controllers. The kits ship with TypeScript, Tailwind v4 and shadcn/ui already wired up.
- A decoupled SPA against a Laravel API – Laravel serves JSON, the React application deploys on its own. Necessary once the same backend has to feed a web app, a mobile app, and a partner integration.
Most of what we ship is the third pattern: Laravel as the API, React on the front. Clients rarely need only a website. The mobile app or the partner integration arrives twelve months later, and a backend that was already an API absorbs that without a rewrite. For admin panels we treat Filament as an add-on rather than a foundation, because generating standard CRUD screens is not work worth billing by hand.
The screening value here is in the reasoning. Anyone who knows only one of the three will recommend it for everything, including the cases where it fits badly. Ask which they would choose for your project, then listen to why. The best answer opens with a question about your roadmap, because that is the judgment you are trying to buy.
The screen for Laravel developers a non-technical buyer can run
Search for Laravel interview questions and you get lists of a hundred, written for interviewers who can already evaluate the answers. Most people who need to hire Laravel developers are not in that position. That is the wrong tool if you are a founder or product owner who cannot read PHP. The five questions below are chosen because the difference between a strong and a weak answer is audible without technical training.
Five questions, and the answers worth hearing
Ask all five in a single call. The pattern across the answers tells you more than any one of them in isolation.
- Which Laravel version was your last project on, and when did you last run a major upgrade? A strong answer names the version, describes an upgrade concretely, and mentions what the test suite caught. A weak answer avoids numbers.
- How do you catch N+1 queries before they reach production? Strong:
preventLazyLoadingin non-production plus a profiler such as Telescope, Debugbar or Pulse. Weak: naming eager loading as the fix without describing how they would find the problem in the first place. - What did you move to a queue on your last project? You want named jobs and a story about a failure that got retried. Anyone can recite what queues are for.
- What does your test suite cover, and will you show me one test? Strong answers describe feature tests that hit real endpoints, running in CI on every push, in either Pest or PHPUnit. If the answer is that the client did not pay for tests, you have learned how the last client's budget conversation went.
- Would you build the admin panel by hand or with Filament? This one is quietly diagnostic. Reaching for a generator on standard CRUD and hand-building only where the domain is unusual protects your budget. A quote of three weeks for screens a package produces in an afternoon tells you where your money would go.
Asking for a code sample instead of a portfolio
A portfolio proves a site exists. It says nothing about who wrote which part of it, and live URLs are the weakest evidence anyone offers in a hiring process. Four specific asks give you far more, and none of them require you to read PHP:
- A read-only invitation to any repository – a side project is fine. The commit history is what you came for.
- One migration file – database structure decisions live here. Even unread, you can ask whether it defines indexes and foreign keys, and whether it can roll back.
- One test file – either they have one to send you or they do not.
- The
composer.jsonfile – the PHP and Laravel version constraints sit at the top, along with every third-party package the project depends on.
From those four you can check several things yourself. Does the commit history show small regular commits, or one "initial commit" containing forty thousand lines? Does composer.json pin ^13.0, or ^8.0? Is there a tests directory at all? A codebase where the answers are steady commits, a current constraint and a populated test directory was written by someone with habits.
Better than any of it: pay for a small trial task. Half a day, tightly scoped, paid at their normal rate. You learn how they ask questions, how they handle ambiguity, and whether the work arrives with tests – which is more than a two-hour interview will ever tell you.
Red flags when hiring Laravel developers
Some signals are reliable enough to act on directly:
- A rate far below the market floor. Nobody with three years of Laravel experience works for $8 an hour by choice.
- No version numbers anywhere in the conversation. Vagueness about versions usually travels with vagueness about upgrades.
- "We should rebuild it from scratch" offered before anyone has read the existing codebase. Sometimes a rewrite is correct. It is never correct as an opening position.
- Tests that only run on the developer's machine. Without CI, a test suite decays quietly until the day someone needs it.
- Reluctance to take a paid trial task. A confident developer treats it as easy money.
- A portfolio made only of screenshots. Images prove a designer was involved somewhere. They say nothing about who wrote the code behind them.
The places to hire Laravel developers, and the going rates
There are four ways to hire Laravel developers, and the price gaps between them track two things: who absorbs the screening work, and who carries the codebase when a person walks away. Both costs are real whether or not they appear on an invoice.
Four routes to hire Laravel developers
| Route | Who does the vetting | When someone leaves | Fits best |
|---|---|---|---|
| Freelance marketplace (Upwork, Fiverr) | You do, from scratch | You start the search again | Small scoped tasks, prototypes |
| Vetted talent platform (Toptal, Laradevs, Arc) | The platform, then you | Platform proposes a replacement, ramp-up is yours | One senior specialist, fast start |
| Software house or nearshore team | The vendor, continuously | Vendor rotates in someone who already knows the project | Ongoing product work, upgrades, multi-role teams |
| In-house employee | You and a recruiter | A full re-hire cycle, three months or more | Long-term core product with a bench to support it |
Two channels deserve a specific mention if you are looking for remote Laravel developers. LaraJobs, the framework's official job board, is where developers who identify with Laravel rather than PHP in general tend to look, which changes the quality of the applicant pool. And if you want the full vendor-selection process rather than the developer-level screen, we covered how to choose a Laravel development agency separately, including contracts and handover terms. The broader trade-offs of moving PHP work outside your own team are in our piece on outsourcing PHP development.
Laravel developer rates in 2026
| Route | Typical hourly rate |
|---|---|
| Freelance marketplace | $15–30, median $20 (Upwork's own PHP data) |
| Vetted talent platform | $50–200+, depending on the platform's markup |
| Software house, Central and Eastern Europe | $25–60 |
| In-house employee | Salary, plus employer contributions, recruitment fee and ramp-up |
That $20 median is a real number and a misleading one, because an hourly rate is not a project cost. What moves the total is rework, the upgrade debt a project accumulates, and whether anything is covered by tests. A developer at $20 an hour whose work needs redoing costs more than one at $50 whose work does not, and you find out which you hired somewhere around month four.
Geography is one axis among several, and it arrives bundled with timezone overlap and legal jurisdiction – we broke the country-by-country picture down in our guide to nearshore software development in Poland. The in-house route deserves an honest accounting too: the salary is the visible part, and the recruitment fee, employer contributions and two to three months of ramp-up are the rest of it.
For context on where we sit: we run a team of 14 Laravel developers, have delivered around 50 Laravel projects, and bill in the $25–60 per hour range with ramp-up usually under two weeks. Version upgrades and migrations off end-of-life PHP are a service we sell, which is a direct consequence of that 40% figure at the top of this article. Somebody has to clean it up.
Right-sizing your Laravel team
The number of developers you need follows from what you are building, and the honest answer is usually smaller than the one you will be quoted:
- One senior, part-time – maintenance, security updates, version upgrades and small features on an application that already works. A single dedicated Laravel developer covers this comfortably.
- One senior plus one mid-level – active development on a live product with a regular release rhythm. The senior sets structure, the mid-level carries volume.
- Senior, mid-level, frontend developer, part-time DevOps – a new build with a React SPA, where backend and frontend can run in parallel from day one.
One caution on scaling up. Adding developers to an unfamiliar Laravel codebase makes it slower before it makes it faster, because onboarding takes one to two weeks per person even on a clean project. If a deadline is already at risk, two new developers will not rescue it. Pick the smallest team that covers the roles you need, and grow it when the work splits cleanly.
FAQ – hiring Laravel developers
Questions that come up repeatedly when clients start this process.
How much does it cost to hire Laravel developers?
Between $15 and $200+ per hour depending on the route. Three factors move that number more than geography does:
- Seniority – a senior at double a junior's rate often costs less across a year, because less gets rebuilt
- Whether tests are included – untested code is cheaper to write and far more expensive to change later
- Who does the screening – marketplace rates look low because the vetting cost sits with you instead
A small scoped piece of work runs to a few thousand dollars. A production application with authentication, payments, an admin panel and a React frontend runs into tens of thousands, and a quote far below that usually means something has been left out of the scope rather than delivered cheaply.
Can a PHP developer work as a Laravel developer?
Often yes, though the transition is less automatic than it sounds. PHP fundamentals, SQL and HTTP all transfer directly. Laravel's conventions do not: Eloquent relationships, the service container, middleware, queues and the testing tools take a few months to absorb properly. The specific risk is a strong PHP developer who writes procedural code inside a Laravel project, producing something that runs correctly and that the next developer struggles to work with.
Should I hire a dedicated Laravel developer or a full team?
Count the roles your project needs before counting the people:
- Backend Laravel work – always required
- Frontend – a separate skill set once you commit to React or Vue
- DevOps and deployment – part-time, but somebody must own it
- QA – optional early, necessary once real users depend on the application
One senior developer can cover backend and deployment on a modest project. Expecting one person to cover Laravel, a React SPA, infrastructure and testing at a professional standard is how projects end up with three of the four done badly.
Where can I hire remote Laravel developers?
Four channels work in practice: LaraJobs for developers embedded in the framework's community, Laracasts forums where the framework's own teaching platform gathers its users, Laravel's official partner directory for agencies the company has vetted, and general marketplaces if you are prepared to do the filtering yourself. The first three produce a narrower and more relevant pool than the fourth.
How do I verify a Laravel developer's skills without a technical background?
You can hire Laravel developers without reading a line of their code, using two mechanisms. First, a paid trial task of half a day to a day, which shows you how they scope, ask questions and hand over work. Second, an independent second opinion: hire a different senior developer for two hours to review the trial output. Two hours of consulting costs far less than three months of the wrong hire, and the reviewer has no stake in the outcome.
Is Laravel still a good choice for a new project in 2026?
For most web applications, yes. Laravel 13 shipped in March 2026 with first-party AI tooling, vector search and JSON:API resources built in, and the ecosystem has commercial products behind it – Forge, Cloud, Nova, Nightwatch – which puts paid revenue behind the roadmap. The honest caveat is talent distribution: PHP's developer population skews experienced, with JetBrains' State of PHP survey of 1,720 PHP developers finding 89% already on PHP 8.x but a long tail of teams still maintaining much older code. Hiring well matters more in that kind of market, which is the whole reason for the screening questions above.
