I have been writing PHP since 2011 — WordPress themes and plugins first, then CodeIgniter applications, then Laravel APIs. That is long enough to have worked on PHP from every era: procedural scripts with SQL in the templates, home-grown MVC frameworks, and modern typed PHP 8 with Composer and strict types. Most of the PHP work I get today falls into two buckets: building something new that should be maintainable for years, and taking over an existing PHP codebase that works but nobody on the team wants to touch any more.
PHP 8 has typed properties, enums, readonly classes, match expressions and a JIT. A codebase written to take advantage of that — strict types, value objects, dependency injection — is as pleasant to maintain as anything in the JavaScript world. When I build new PHP I write it that way, and when the project calls for a framework I reach for Laravel rather than reinventing routing and queues.
A lot of US companies run on PHP written years ago by a developer or agency that has since moved on. It works, it makes money, and every change feels risky. I start by getting it under version control, into a reproducible local environment and behind a deployment process that is not FTP. Then I add tests around the parts that matter and refactor in small, shippable steps. No rewrite fantasy — just a codebase that gets safer to change every week.
Hosting providers retire old PHP versions on their own schedule, and an application stuck on PHP 7.4 is one control-panel update away from a white screen. I run static analysis to find incompatibilities, fix deprecations, update dependencies, and verify the upgrade on staging against real traffic patterns. The same applies to WordPress sites carrying old plugins and themes.
Both. Laravel is my default for new applications, but I regularly work in plain PHP, CodeIgniter, WordPress and custom in-house frameworks. The goal is to improve what you have, not to force a framework onto it.
Yes. I audit the codebase and its dependencies for incompatibilities, fix them on a branch, and test on a staging environment before switching production. Most upgrades are a matter of days to a couple of weeks, depending on how many outdated dependencies are involved.
You get senior-level experience — fifteen years of shipping PHP for agencies and product teams — at a rate that is usually well below a comparable US contractor, with fluent English and working hours that overlap with the US business day. I explain the practical details on the hire a PHP developer page.
Yes. I am a full-stack developer: the PHP backend and a React or Next.js frontend, or a server-rendered PHP frontend if that suits the project better. One person owning both sides means fewer handoffs.