A shortlist in 72 hours, contributing inside two weeks, and a 30-day guarantee if the fit is wrong.
72-hour shortlist · 30-day replacement guarantee · Month-to-month
PHP runs a large share of the web, and it has been doing so long enough that the label now covers two nearly unrelated skill sets.
Modern PHP is a typed, tooled language. Constructor property promotion, enums, readonly properties, union types, match, and a static analyser that will refuse your build. Laravel on top of that gives you a container, a capable ORM, first-class queues and a real testing story. Teams building on that stack are doing ordinary, serious engineering.
The other PHP is still out there in volume: procedural files, SQL assembled by string concatenation, no autoloader, no Composer, no tests, written by somebody whose habits formed before PHP 7 and were never revisited. Both groups apply for the same roles and describe themselves in the same words.
The spread is the entire problem. In most stacks the distance between the middle of the market and the top is speed. In PHP it is closer to a difference in kind, and a CV will not tell you which one is sitting in front of you.
In a market this wide, screening is mostly about establishing which decade someone learned in.
Typed properties, enums, constructor promotion and match — or PHP 5 habits carried forward intact. We look at code, not at the version on the CV.
N+1 awareness, eager loading, and whether they run Model::preventLazyLoading() in development. The most predictive Laravel question we ask.
Whether business rules end up in controllers, and what they do about it when they inherit an application where they already have.
Failed jobs, retries, idempotency, and what happens when a worker dies mid-job. Documentation knowledge and production knowledge diverge sharply here.
PHPUnit or Pest, and whether they have worked under PHPStan at a level strict enough to be inconvenient.
A live conversation in English, every time. In a market this wide we would rather hear somebody reason through a trade-off than recite a package list.
The Laravel failure mode is an application that is pleasant to work in for six months and then gets slow all at once.
Eloquent makes the N+1 query problem effortless to write and invisible in review. A controller loads fifty orders, the template asks each one for its customer, and the page issues fifty-one queries instead of two. On a developer machine with two hundred seeded rows it is imperceptible. In production against real data it is a four-second page, and the fix — one with() call — is only easy once somebody has worked out which of the thirty relationships being touched is responsible.
Laravel ships a switch for exactly this. Model::preventLazyLoading() in your non-production environments turns every lazy load into an exception, so the bug is caught by the developer who wrote it rather than by a customer. Asking whether a candidate runs it is one of the most efficient screening questions available in this stack.
The structural cost is business logic living in controllers. A controller method that validates, calculates, writes to three tables and dispatches an email works perfectly well. It is also untestable without booting HTTP, unreachable from a queue worker or a console command, and duplicated the moment the same rule is needed somewhere else. Once there are two copies that disagree, the question "what are our refund rules" no longer has an answer anybody can look up.
Then there are transactions. Multi-table writes without DB::transaction() leave half-finished records behind every time something throws midway through. Nothing alerts. You find out during a reconciliation months later, with no reliable way to reconstruct which rows are wrong.
Mid-level (3–5 years). Builds features inside an existing Laravel application. Comfortable with Eloquent, validation, Blade, and the queue system as somebody else configured it. Needs direction on where logic belongs.
Senior (5–8 years). Decides the structure — what becomes a service, what becomes a job, what stays on the model. Owns query performance, sets the testing standard, and can drive a PHP version upgrade across the estate without breaking it.
Lead (8+ years). Owns architecture across applications, makes the Livewire-versus-Inertia-versus-separate-frontend call, plans how the legacy system gets strangled, and sets the static analysis level everybody else has to pass.
Feature work on an existing Laravel application. The largest category by a distance, and the easiest to staff well.
Legacy PHP into Laravel. A CodeIgniter, Zend or bespoke application being strangled one route at a time. Needs somebody comfortable in both worlds, which is a narrower pool than either on its own.
PHP version upgrades. Usually forced by a hosting deadline or a security scan. Bounded, unglamorous, and consistently underestimated because the breakages live in dependencies rather than in your code.
API backends for a JavaScript frontend. Laravel serving JSON to React or Vue. Frequently paired with React or Vue.js developers on the same engagement.
Performance rescue. An application that has become slow with no obvious cause. Almost always queries, occasionally queues, very rarely the language itself.
Week one. They install a query profiler before writing anything — Telescope, Debugbar, Clockwork, whichever you already run — and look at the query count on your three busiest pages. Expect a number back by day three, and expect it to be higher than anyone in the room guessed. Expect questions about where business rules currently live and whether the test suite runs at all.
Weeks two to four. A shipped feature, plus one concrete cleanup they can justify in a sentence: a controller broken up, an N+1 removed from a hot path, a transaction wrapped around a multi-table write. Small and defensible, not a proposal to restructure the application.
The warning sign is a developer who wants to add abstraction immediately. A repository interface over Eloquent, a service class for every model, an event for every action. It reads as good practice and usually is not, because Laravel already provides those seams. Somebody proposing an architectural overhaul in week two has not read enough of the codebase yet to know what is actually wrong with it.
Screening on "PHP" instead of on the version and the framework. The distance between PHP 5.6 procedural code and a typed Laravel application running PHPStan at a level that hurts is larger than the distance between many separate languages. Name both in the brief.
Accepting "I know Laravel" without asking what they have run in production. Building CRUD from the documentation teaches routing and Eloquent. It teaches nothing about failed jobs, retry storms, or what happens when a job executes twice because the worker was killed mid-run. Ask about the queue and listen for whether the answer contains specifics.
Judging on framework opinions rather than on code. The facade debate, repositories, domain-driven design in Laravel — these are cheap views to hold and tell you very little. A better test is thirty minutes inside your actual codebase and the question of what they would change first. Strong candidates pick something small and explain the consequence of leaving it.
Underestimating a version upgrade. Your own code is usually the straightforward part. The cost sits in abandoned packages, a payment SDK two majors behind, and the one dependency pinning an old constraint that blocks everything else. Inventory Composer before you commit to a date.
Rates depend on seniority, application complexity, and engagement length. Tell us the role and we will give you a firm number.
Tell us the role and we will send a shortlist within 72 hours.
Tell Us the RoleTell us the role. Three to five profiles within 72 hours.