Hire PHP Developers: Rates, Vetting and Engagement Models

PHP developers get hired because something already exists

PHP developers rarely get hired to start something. They get hired because something is already running, it is making money, and it is scaring everyone. A Laravel app on 8.x that nobody has upgraded since the original contractor left. A WooCommerce store with 40 plugins and a checkout that intermittently double charges. A twelve year old CodeIgniter admin panel that the operations team lives in eight hours a day. That is the real job: reading someone else's decisions and changing them without breaking revenue.

Take a Laravel 6 marketplace we inherited. About 90,000 lines of application code, a 400 line controller method handling order placement, and no queue worker. Every order fired a synchronous call to a shipping API inside the request cycle. When the shipping vendor got slow, PHP-FPM ran out of workers, and the whole site went down: checkout, admin, everything. The client thought they had a hosting problem and had already upsized the server twice. They had a code problem, specifically blocking I/O in a web request, no jobs table, and no timeout on the Guzzle client. A developer who has run production PHP sees that in twenty minutes. A developer who has only built greenfield CRUD apps sees a server that needs more RAM.

That is the gap you are hiring across. PHP is easy to write badly and the language will not stop you. It will happily let someone put database queries inside a Blade loop, ship an N+1 that runs 800 queries per page, store passwords with md5 because a Stack Overflow answer from 2011 said so, and interpolate request input straight into a raw query. The bad hire is not the person who cannot code. It is the person who codes fluently in the exact style that created your current mess.

Where hiring goes wrong, specifically: buyers screen for "PHP" and get someone who knows one framework's syntax but not PHP itself. Laravel has an enormous surface of conveniences, and you can be productive in it for years without understanding what an ORM is doing, what a service container resolves, or why your Eloquent relationship just loaded the entire table into memory. Ask about the framework and you learn nothing. Ask what happens between the request hitting Nginx and the response leaving, and the room sorts itself out fast.

Engagement models: what each one is honestly for

In-house hire. Right when the PHP app is your product and will be for years, and you have enough work to keep someone busy every week. The value is accumulated context: after six months a good in-house PHP developer knows why that weird nullable column exists and which cron job actually matters. The cost is that you are also buying recruiting, onboarding, management, and single-person risk. One PHP developer alone is a bus factor of one, and PHP codebases are unusually good at hiding tribal knowledge in undocumented helper files.

Freelancer. Right for bounded, well-specified work: build this WooCommerce plugin, integrate this payment provider, upgrade Laravel 9 to 11. Genuinely good when the scope has edges. It falls apart on open-ended maintenance, because a freelancer with three other clients will always deprioritise your Tuesday incident, and because nobody is reviewing their pull requests. The failure we see most: a freelancer builds something that works, disappears, and nobody can extend it because it uses a pattern nobody else on the team recognises.

Agency. Right when you need the whole outcome, not the hands: someone to decide the architecture, do the work, test it, deploy it, and be accountable if it breaks. You are paying for a team that includes review and QA. It is worse than freelancing when your scope is a two week task, because agency overhead is real and you will pay for process you did not need.

Staff augmentation. Right when you have technical leadership already and need capacity that behaves like your team. The developer sits in your standups, uses your repo, follows your conventions. This is where most PHP work should land, because most PHP work is ongoing maintenance and extension of a live system, which needs continuity but not a permanent headcount. The catch is that you have to actually lead them. Augmentation with no technical owner on your side turns into a very expensive freelancer.

Rates and what it really costs

These are the bands we quote and the bands we lose deals against. They move a lot by region and seniority, so treat them as shape, not price list.

Offshore, meaning India, Pakistan, Bangladesh, Vietnam, the range runs roughly $25 to $55 per hour for mid to senior. Eastern Europe and Latin America land around $60 to $110. Onshore in the US, UK or Western Europe, $95 to $175, with the higher end for people who do Laravel performance work, payment integrations, or legacy rescue. Junior PHP is cheap everywhere and is almost always a false economy on a live revenue system, because what you save on the rate you spend twice on the incident.

The band matters less than the specialisation. A generalist who "does PHP" and a person who has upgraded four Laravel majors and knows what Laravel Shift will and will not handle are not the same purchase, even at the same rate. Framework depth compresses timelines more than raw seniority does.

On in-house total cost, the salary is the headline and not the number. Benefits, payroll taxes, insurance, equipment, software licences and desk overhead push the fully loaded cost well above base rather than near it. Then add recruiting, which is either a placement fee tied to first year salary or your own engineering team's hours spent screening. Then add ramp. On a mature PHP codebase, especially a legacy one with thin tests, we do not expect a new hire to be shipping confidently for six to ten weeks. They spend the first month reading. Price that month, because you are paying for it either way.

The comparison people get wrong: they compare a contractor's hourly rate to a salaried developer's hourly equivalent and conclude the contractor is expensive. The real comparison is fully loaded cost plus recruiting amortised plus ramp plus the risk that you hire wrong and repeat the whole cycle in five months.

How to vet a PHP developer

Skip trivia. Nobody needs to recite the arguments of array_splice. What you are testing is whether they understand what PHP is doing underneath the framework, and whether they have operated code in production.

The request lifecycle question. Ask them to walk you from a browser request through Nginx, PHP-FPM, the framework bootstrap, to the response. Good answers mention FPM worker pools, that PHP is shared-nothing per request, that the framework boots on every request, and where OPcache fits. If they cannot describe FPM, they have never debugged a site that fell over under load.

The N+1 question. Give them a small Eloquent or Doctrine snippet that loops over orders and touches a relationship inside the loop. Ask what the database sees. Then ask them to fix it. You want eager loading named without prompting, and ideally a mention of Laravel Debugbar, Telescope, or query logging to find these rather than guessing.

The upgrade question. "We are on Laravel 8 and PHP 7.4. Take me through getting to Laravel 11 and PHP 8.3." Strong candidates talk about sequencing majors one at a time, running Rector or Laravel Shift as a starting point rather than a solution, checking every composer dependency for a compatible version first, the risk that an abandoned package blocks the whole chain, and doing all of it behind a test suite. Weak candidates say they will just update composer.json.

The security question. Ask what they do with user input that reaches a query. You want prepared statements and parameter binding, not "I escape it". Ask about mass assignment protection, CSRF, and how they store passwords. If they mention md5 or sha1 for passwords, or say they write raw queries with escaped strings, end it there. Ask what they would do if they found API keys committed in the repo, which happens in PHP projects constantly.

Take-home or portfolio review. Do not commission a fresh CRUD app, it tells you nothing. Give them a small, deliberately ugly slice of real-shaped legacy code: a fat controller with a database query, a business rule, and an external API call all tangled together, no tests. Ask them to refactor it and add tests, timeboxed to three or four hours, and pay them for it. What you are grading: do they extract the business logic somewhere testable, do they mock the external call, do they touch the database in the test or use a factory, do they leave the public behaviour identical. Then have them walk you through their reasoning live. The walkthrough matters more than the code.

If you are reviewing existing work instead, ask for a repo and go straight to composer.json to see how current their dependencies are, then look for a tests directory, then read one controller. Three files tell you almost everything. Also ask them to describe the worst production incident they caused. People who have operated PHP have a story and tell it plainly. People who have not, deflect.

Red flags

They say "PHP" but mean one framework. Someone who can only work inside Laravel's conventions will stall the moment your code does something unconventional, which legacy code does constantly. Ask instead: "What does the service container actually do when you type-hint a class in a constructor?" A shrug means they are using magic they cannot debug.

No mention of tests, ever. PHP's culture is split, and a large share of working PHP developers have genuinely never written a PHPUnit or Pest test. On a system you cannot afford to break, that is disqualifying. Ask instead: "How would you change the order total calculation without shipping a bug?" If the answer does not involve a test, they are proposing to change your billing logic on vibes.

The rewrite reflex. A developer who looks at your working legacy app and immediately proposes rebuilding it in Laravel is telling you they cannot read code they did not write. Rewrites of revenue systems are how six month projects become two year projects. Ask instead: "What is the smallest change that fixes the checkout bug without touching anything else?"

Ships to production by FTP or by editing files on the server. Still common, and it means no version control discipline, no rollback, no review. Ask instead: "Walk me through your deploy. What happens if the release is bad?" You want git, a deployment tool like Deployer or Envoyer or a CI pipeline, and a rollback answer.

WordPress plugin developer applying for application work. Not an insult, a mismatch. WordPress work is real skill, but it trains different instincts: global functions, hooks, plugin-first thinking. Dropping that person into a domain-heavy Laravel or Symfony codebase goes badly for both sides. Ask instead: "Tell me about a time you had to model business rules that did not fit a plugin." Then listen for whether they reach for architecture or for another plugin.

When to hire a PHP developer at all, and how we staff it

Hire PHP when you have PHP. That sounds obvious and it is the whole point. If a Laravel, Symfony, WordPress or legacy PHP application is already running your business, hire someone who knows that world deeply, because rewriting it in Node or Python to match your preferences is a business decision disguised as a technical one, and it usually costs a year.

Do not hire a PHP developer if your actual problem is elsewhere. If the pain is a slow, unindexed database, you may need a database specialist for two weeks, not a full-time PHP hire. If the pain is that your site falls over under traffic, that is often infrastructure and queue design as much as application code. If you are starting genuinely new and have no PHP investment, choose your stack on your hiring market and your team, not on this page. And if the app is a content site with a few forms, a WordPress specialist will serve you better and cheaper than an application developer.

How Digital Heroes staffs this: we read the code before quoting, because a PHP estimate made without seeing composer.json and one controller is a guess. We staff PHP work as a pod rather than a lone body, so there is a senior who owns the architecture and reviews every pull request, and a developer doing the day-to-day, which means your changes get a second reader and your project does not stop when one person takes leave. We match on the specific thing you have, so a WooCommerce checkout problem gets someone who has debugged WooCommerce checkouts, not a Laravel generalist learning on your money. And we sequence hard problems first: on legacy engagements the upgrade path, the security holes and the tests come before the feature roadmap, because features built on a cracked foundation get rebuilt anyway. Where the code needs to end up owned by your team, we write it to be handed over, with a test suite and a deploy pipeline, so you are not buying dependence on us.