Hire Laravel developers

Laravel is the PHP framework most new commercial PHP work is built on, and hiring for it means checking whether someone knows the framework's conventions or merely its syntax.

What Laravel actually is

Laravel is a PHP web framework with an unusually complete set of built-in capabilities: routing, an object-relational mapper, queues, scheduling, authentication, mail, events, caching and a testing framework. It is developed by a company that also sells hosting and supporting products, and it releases on a predictable annual cadence with dated support windows for each version.

Its defining characteristic is that it has an opinion about almost everything, and following those opinions produces working software very quickly. That is genuinely valuable, particularly for products that need to reach customers before they need to scale. The corresponding risk is that developers can be productive within the conventions without understanding what sits underneath them, and that gap only becomes visible when something unusual is required.

For hiring, the practical consequence is that Laravel experience is easy to claim and easy to verify. The framework's conventions are specific enough that a short conversation about queues, the ORM, or how a request becomes a response will separate someone who has built and operated a Laravel application from someone who has followed tutorials through a CRUD example.

The part that separates seniors from mid-levels

The service container is the framework's foundation, and understanding it is what separates levels. Almost everything in Laravel is resolved through it, bound in service providers, and injected where needed. A developer who understands the container can extend the framework cleanly, write testable code and diagnose the puzzling class of bug where the wrong implementation is resolved. One who does not tends to reach for facades and helper functions everywhere, producing code that works and cannot be tested in isolation.

Eloquent, the ORM, is the second area and the source of most Laravel performance problems. It is expressive and it makes it very easy to issue a query per record without noticing. The N plus one pattern is the single most common fault we find in Laravel applications, and it is invisible with a small development dataset. Candidates who mention eager loading unprompted, or who describe using a query log to find the problem, are telling you they have run an application under real data.

Queues and scheduled work are the third area, and the one that most distinguishes applications that survive growth. Laravel makes it trivial to push work to a queue, and much less trivial to handle what happens when that work fails repeatedly, runs twice, or runs against data that has since changed. Failed job handling, idempotency and retry strategy are where the real experience shows.

Where Laravel is used

The label “Laravel developer” covers several jobs that share a technology and little else. These are the settings the work usually turns up in, and the one you are hiring into should shape the whole process, because the judgement each demands is different.

SaaS products

Subscription applications where the framework's built-in authentication, billing integrations and queues cover most of the undifferentiated work.

Internal business systems

Operations, inventory and back-office applications, frequently replacing spreadsheets or an older custom system.

APIs for mobile and single-page applications

Back ends serving a separate front end, using the framework's API tooling and token authentication.

Marketplaces and booking systems

Multi-party applications with payments, notifications and scheduled work, which the framework supports well out of the box.

Agency and client work

A very large share of Laravel work, where delivery speed is the main commercial driver.

Replacements for legacy PHP

Custom older applications being strangled route by route behind a Laravel front end.

If a candidate's experience sits in a different row of that list from the work you have, that is not a reason to reject them, but it is the thing to probe. Ask what would be different about their approach in your setting. Someone who can answer that has transferable judgement. Someone who says it would be much the same has probably not thought about it.

Which Laravel versions are still supported

Laravel releases annually with published bug-fix and security-fix windows for each version, so how far behind an application has fallen is a matter of record.

The table is generated from public release data rather than written by hand, so it states what is supported today rather than what was true when any given article was published. Of the 8 most recent release lines, 2 are still maintained and 6 have passed their published end-of-life date. That distinction is the practical one when you read a job specification: a requirement written against a line that is now out of support tells you the specification is older than the codebase it describes, and it is worth asking which of the two the new developer will actually work in.

Source: endoflife.date public release data, read 2026-09-25.

Two questions follow from this table in an interview. The first is which line the candidate has most recently shipped against, because someone whose last production work was on an unsupported line has not had to deal with the changes since. The second is how they have handled an upgrade. Version migrations are where you see whether a developer reads release notes, writes characterisation tests before changing anything, and knows how to stage a rollout, or whether they upgrade in place on a Friday and hope.

The toolchain around it

Nobody hires for Laravel alone. The surrounding tools are where most of the day-to-day work happens, and a gap in any of them costs more time than a gap in the core library. This is the set that turns up most often on real job specifications alongside it.

PHP

The language underneath. Framework skill without language depth has a visible ceiling.

Eloquent

The ORM, and the thing to interview about if you interview about only one.

MySQL or PostgreSQL

The data store, with MySQL most common in the Laravel world.

Redis with Horizon

Queues and caching, with a dashboard for monitoring workers.

Pest or PHPUnit

Testing. Laravel's testing support is strong, so an untested Laravel codebase is a choice rather than a constraint.

Livewire or Inertia

Interactive interfaces without a separate front-end application, a common and consequential architectural choice.

Laravel Forge or a container platform

Deployment. Forge is common in smaller teams, containers in larger ones.

Telescope and a profiler

Local debugging, including the query log that reveals N plus one problems.

Related skills that frequently appear on the same specification: PHP, MySQL, React, Vue.js, AWS.

What to test in an interview

These are the topics that separate candidates in practice. Each one is given with why it discriminates, what a strong answer sounds like, and the response that should make you slow down. None of them requires a whiteboard.

The service container

The framework's foundation, and the clearest divider between competent and superficial Laravel experience.

• Strong answer: Explains binding and resolution, uses constructor injection, and can describe extending or swapping a framework service.
• Warning sign: Uses facades and helpers everywhere and cannot explain how a dependency is resolved.

Eloquent and the N plus one problem

The most common performance fault in Laravel applications by a wide margin.

• Strong answer: Eager loads deliberately, watches the query log, and can describe finding and fixing a case in production.
• Warning sign: Has never inspected the queries an application issues.

Queues and failure handling

Pushing work to a queue is easy; operating one is not.

• Strong answer: Handles failed jobs, designs for idempotency, understands retries and backoff, and has monitored workers.
• Warning sign: Has used queues but never thought about a job running twice.

Testing approach

Laravel makes testing easy, so its absence says something.

• Strong answer: Feature tests through the HTTP layer against a real database, with fast focused unit tests where logic is complex.
• Warning sign: Mocks the ORM, or has worked only on untested Laravel applications.

Authorisation design

Laravel gives several mechanisms, and mixing them produces gaps.

• Strong answer: Uses policies consistently, checks at the point of access rather than only in the interface, and can explain where a check would be missed.
• Warning sign: Hides interface elements and considers the resource protected.

Livewire, Inertia or a separate front end

A significant architectural decision that is often made by default.

• Strong answer: Can explain the trade-offs and when each is appropriate for the team and the product.
• Warning sign: Has only used one and treats it as the only approach.

Upgrading across major versions

Annual releases mean this recurs, and applications that skip it accumulate risk.

• Strong answer: Has run an upgrade, uses the published guide, and keeps the application close to current.
• Warning sign: Has only worked on applications that never moved version.

Warning signs in a Laravel codebase

The fastest way to read a candidate is to ask what they have found wrong in code they inherited. These are the patterns that come up most often, what they cost, and what fixing them looks like. A developer who recognises three or four of these from their own experience is worth more than one who can recite the documentation.

The N plus one query

• What you see: A loop over models that accesses a relationship on each iteration.
• What it costs: Hundreds of queries where two would do. Fine with ten records in development, crippling with ten thousand in production.
• The fix: Eager load explicitly. Enable strict mode so lazy loading raises an error in development rather than passing silently.

Fat controllers

• What you see: Controllers of several hundred lines holding business logic.
• What it costs: Nothing is reusable or testable in isolation, and every change to a rule risks unrelated endpoints.
• The fix: Move logic into dedicated action or service classes. Keep controllers to receiving a request and returning a response.

Facades everywhere

• What you see: Static facade calls throughout the application instead of injected dependencies.
• What it costs: Hidden dependencies and code that can only be tested with the whole framework booted.
• The fix: Inject through the constructor. Reserve facades for genuinely global concerns in thin layers.

Mass assignment left open

• What you see: Models with every attribute fillable, populated directly from request input.
• What it costs: Users can set fields they should not, including roles and flags. A recurring source of real vulnerabilities.
• The fix: Be explicit about what is fillable, and validate request input into a typed object before it reaches a model.

Business logic in model events

• What you see: Significant behaviour triggered by saving a model.
• What it costs: Invisible side effects that fire from tests, seeders and unrelated code, producing surprising behaviour.
• The fix: Use explicit application services. Keep model events for narrow concerns such as setting a derived field.

Queue work with no idempotency

• What you see: Jobs that assume exactly-once execution.
• What it costs: Duplicate charges, duplicate emails and duplicate records when a job retries after a timeout.
• The fix: Make jobs safe to run twice. Assume at-least-once delivery, because that is what you have.

What each level can own

Job titles are not comparable between companies, so it is more useful to describe levels by what a person can be left to own without supervision. These are the boundaries we use when we assess a Laravel developer.

Junior

Builds CRUD features following the framework's conventions. Needs review on query patterns and authorisation.

Mid-level

Owns a feature area including queues, tests and authorisation. Can find an N plus one problem without being told to look.

Senior

Owns application architecture, the queue and caching strategy, and the front-end approach. Can keep an application current across versions without stopping delivery.

Staff

Owns the boundary between the framework and the domain, the upgrade policy, and the decision about when the application has outgrown the conventions.

How the work is usually scoped

Team shape follows the kind of work, not the headcount you happen to have budget for. These are the shapes that come up most often and the constraint that actually governs each one.

New SaaS application

• Usual team: One to two developers.
• What governs it: Laravel reaches a working product quickly. Billing, permissions and the queue strategy are what to design deliberately.

API for a separate front end

• Usual team: One developer.
• What governs it: Scoped by integrations rather than endpoints. Token handling and versioning are the parts usually underestimated.

Legacy PHP replacement

• Usual team: Two developers, one who knows the old system.
• What governs it: Strangle route by route. Data migration is the hard part and is often discovered late.

Performance remediation

• Usual team: One senior developer, time-boxed.
• What governs it: Nearly always queries. A query log and an afternoon usually identifies most of the problem.

Version upgrade

• Usual team: One developer.
• What governs it: Routine if the application is one version behind, a project if it is four and has no tests.

Migration work you may actually be hiring for

A large share of Laravel work is not new development. It is moving an existing system from one state to another while it stays in service. These are the migrations that come up most often, and each one asks for a different kind of experience from the person you hire.

An older Laravel version to the current release

• Why teams do it: Security support, access to current packages, and avoiding a larger jump later.
• What to watch: Use the published upgrade guide version by version rather than jumping several at once. The package ecosystem is usually the constraint, so check each dependency's compatibility before starting.

Blade with jQuery to Livewire or Inertia

• Why teams do it: Modern interactivity without abandoning the PHP-first model or building a separate front-end application.
• What to watch: Livewire changes how state and requests work, so it is a genuine architectural shift rather than a templating change. Convert a few pages first and confirm the request volume is acceptable.

Synchronous request processing to queued jobs

• Why teams do it: Removing slow third-party calls and heavy work from the request path.
• What to watch: Idempotency and failed job handling are the project. A queue without a strategy for repeated failure moves the problem out of sight rather than solving it.

A custom legacy PHP application to Laravel

• Why teams do it: A testable structure, an upgrade path, and a hiring pool that recognises the conventions.
• What to watch: Route by route behind a shared front door, with the legacy application still serving everything not yet moved. Shared sessions and authentication between the two are the fiddly part and should be solved first.

Migration work rewards a different temperament from greenfield work. The useful question in an interview is not whether someone has done the specific migration you face, but whether they have ever run one incrementally: behind a flag, with both paths live, and with a way back. Developers who have only done big-bang cutovers tend to propose them again.

What a good brief for this role contains

Most of the time lost in hiring a Laravel developer is lost before anyone is interviewed, in the gap between what the brief says and what the team actually needs. These are the points that, for this technology specifically, change who the right candidate is. A brief that answers them can be matched in days. One that does not produces a shortlist that looks reasonable and converts badly.

• Which Laravel version the application is on, and how far behind current that is.
• What the front-end approach is: Blade, Livewire, Inertia, or a separate application.
• Whether queues and scheduled jobs are in use, and whether the person will be responsible for them failing.
• What tests exist, because an untested Laravel application is unusual and tells you something about how it has been run.
• Whether the work is new features, performance, or replacing a legacy system behind the framework.
• What third-party integrations exist, since payments and mail are usually where onboarding time actually goes.

If you cannot answer some of these yet, that is normal and it is still worth writing down which ones are open. An unknown that is named can be worked around. An unknown that is papered over in a job specification turns into a rejected shortlist and a restart four weeks later.

What the US market pays for this work

Laravel work is counted by the US Bureau of Labor Statistics under Software Developers. That classification is broader than the technology itself, so treat the figures as the shape of the market a Laravel developer is hired into rather than as a rate card for the skill. Across the United States the Bureau counts 1,687,890 people in this occupation, with a median annual wage of $135,980.

The spread matters more than the midpoint. The 90th percentile is about 2.6 times the 10th, which is a wide band for a single occupation and tells you that the title on its own carries very little pricing information. Two people described as a Laravel developer can sit at $82,460 and $214,670 in the same national dataset. When a budget is set from a median without asking which end of that range the work actually needs, the hire that follows is usually the wrong one in one direction or the other.

Related classifications are worth reading alongside it, because teams hiring for Laravel frequently end up recruiting against these titles too:

Source: BLS Occupational Employment and Wage Statistics, May 2025. Figures cover all US employers and are not FuturByte rates.

These are employer-side wage figures for people on a US payroll. They exclude employer taxes, benefits, recruitment cost and the months a seat sits empty, all of which are real and none of which appear in a salary line. The useful way to read the table is as the cost of the alternative you are comparing against, not as a number to match.

How US metro markets compare for this role

The same job is priced very differently across the country. Ranked by median annual wage for Software Developers, the gap between the highest and lowest of the 28 metro areas covered here is a factor of about 1.7. San Jose sits at the top with a median of $213,110; Pittsburgh sits at the bottom with $124,500. A budget built from a national median will be wrong in both of those markets, in opposite directions.

Location quotient compares how concentrated this occupation is in the metro against the national average. A value above 1 means the metro has more of this work than its size would predict.

The location quotient column is the more useful one for hiring. A high median tells you what a role costs; a high quotient tells you whether the people exist. San Jose, San Francisco, Seattle, Washington, D.C., Denver, Austin each have a quotient of 1.5 or above, meaning the work is concentrated there well beyond what the size of the local economy would predict. Those are the markets where a search is likely to be quick and competitive at the same time, and where a counter-offer is most likely to take a candidate off the table late in the process.

The opposite case is worth planning for too. In a metro with a low quotient, the total pool is small even when wages look reasonable, so the realistic options are to widen the search radius, accept a longer time to hire, or bring the capability in from outside the local market entirely. That last option is what most teams are weighing when they come to us.

Hiring risks worth naming

Every one of these has produced a bad hire somewhere. They are written down so that the process tests for them deliberately rather than discovering them in month three.

Tutorial-depth experience. Ask about the container and about queue failures. Both are hard to answer without real project experience.

No production operating experience. Ask what broke after launch. Queue and performance problems only appear under real data and real traffic.

Framework knowledge without PHP depth. Matters when something needs to happen outside the conventions, which it eventually does.

Applications kept far behind on version. Ask when they last upgraded. Habitual deferral is a working culture rather than a circumstance.

Hiring Laravel developers by metro area

Wages for this occupation vary more between US metro areas than most budget models assume. Each page below sets out the published employment and wage figures for that market, how it compares with the national picture, and what the local industry mix means for the kind of Laravel developer who will be available.

• New York, NY $166,830 median
• Seattle, WA $167,280 median
• San Jose, CA $213,110 median
• Washington, D.C. $154,930 median
• San Francisco, CA $186,640 median
• Dallas-Fort Worth, TX $133,290 median
• Los Angeles, CA $160,920 median
• Boston, MA $166,090 median
• Chicago, IL $134,380 median
• Atlanta, GA $132,960 median
• Austin, TX $134,120 median
• Phoenix, AZ $131,750 median
• Philadelphia, PA $133,040 median
• Minneapolis-St. Paul, MN $130,920 median
• Denver, CO $137,610 median
• Detroit, MI $130,760 median
• Houston, TX $129,440 median
• Charlotte, NC $135,920 median
• San Diego, CA $163,270 median
• Salt Lake City, UT $129,600 median
• Miami, FL $132,650 median
• Portland, OR $156,000 median
• Baltimore, MD $138,900 median
• Tampa, FL $130,450 median
• Orlando, FL $129,620 median
• Raleigh, NC $132,770 median
• Kansas City, MO $124,990 median
• Pittsburgh, PA $124,500 median

Frequently asked questions

Is Laravel suitable for a serious commercial product?

Yes, and a great many funded products run on it. It is particularly strong where the application has a lot of ordinary web-application work such as authentication, billing, notifications, scheduled jobs and background processing, because all of that is provided rather than assembled. It is less obviously the right choice for workloads dominated by heavy computation or by very high request throughput.

How do we test for real Laravel experience?

Ask how they would find out why a page issues four hundred queries, and ask what happens when a queued job fails three times. Both questions are answerable in a sentence by anyone who has operated a Laravel application and are difficult to answer convincingly from tutorials.

Should we use Livewire, Inertia or a separate front end?

Livewire when the team is PHP-first and the interactivity is moderate; it avoids a second codebase entirely. Inertia when you want React or Vue components without building a separate API. A fully separate front end when you have dedicated front-end engineers or more than one client application. The wrong answer is choosing by default and discovering the constraint later.

Why is our Laravel application slow?

In almost every case we examine it is the N plus one query pattern, sometimes combined with missing indexes. It is invisible in development and severe in production because the cost scales with the number of records. Enabling strict mode so lazy loading throws an error in development prevents the whole class of problem from reappearing.

How often should we upgrade Laravel?

Annually, in line with the release cadence, and treat it as routine maintenance rather than a project. Applications that stay within one version of current upgrade in days. Applications that fall four versions behind need a dedicated effort, and the cost of catching up grows faster than the cost of keeping up.

Can a Laravel developer work on our legacy PHP?

Often yes, and it is worth asking rather than assuming. The skills transfer more readily in this direction than the reverse, but the temperament does not always: some developers who enjoy framework work find legacy maintenance frustrating. Ask directly, because a mismatch here produces an unhappy hire rather than an incapable one.

Is Laravel's ecosystem a lock-in risk?

The framework is open source and permissively licensed, so the code is not locked in. Some of the surrounding commercial products are convenient enough that teams become dependent on them, particularly for deployment and queue monitoring. Those are replaceable, and it is worth knowing which ones you use before you need to replace them.

What should we give a Laravel developer on day one?

A working local environment with realistic seed data, queue workers running, and access to whatever third-party services the application integrates with. The last one is what most often stalls a first week, because payment and mail integrations rarely work from a fresh checkout without credentials somebody has to go and find.