Custom application work
Business logic, admin panels, reporting, integrations with payment and shipping providers, and the unglamorous CRUD screens that most internal tools are actually made of.
Web & Application Development
Servers, Hosting & DevOps
AI & Automation
Performance, Security & Care
Web & Application Development
Most PHP work I take on falls into one of two buckets: building something new on PHP 8 with modern tooling, or carefully untangling an older codebase that has been running for years and cannot simply be thrown away.
Both matter. A ten-year-old PHP application that still processes orders every day is a business asset, not an embarrassment. The job is usually to make it safe to change again, add tests around the risky parts, move it onto a supported PHP version, and replace the worst pieces one at a time without a big-bang rewrite.
How I work on it
Adjusted to the job, but this is the shape it usually takes.
Before quoting anything I read the codebase and the server it runs on. Estimates made without that are guesses.
We write down what is fragile, what is security-critical and what can safely be left alone. Not everything needs fixing.
Changes ship in reviewable pieces so a regression is easy to trace and roll back.
Setup steps, environment variables and known quirks get written down so the next person is not starting from zero.
Questions
Yes. That describes most legacy PHP. The first thing I do is add characterisation tests around whatever we are about to change, so we can tell if a refactor broke behaviour.
Sometimes, but rarely as a first move. A full rewrite means running two systems in parallel for months. More often we upgrade the PHP version, add Composer, and then strangle out modules one at a time, and that path can end in Laravel without the risk of a hard cutover.
Usually yes. Shared cPanel hosting, a VPS or a managed platform all work, though shared hosting does limit things like queue workers and long-running processes, and I will say so if that becomes the constraint.