Web & Application Development

PHP 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.

What is included

The work itself

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.

Legacy upgrades

Moving code off PHP 5.x/7.x onto a supported release, replacing removed extensions like mysql_*, and fixing the deprecation warnings that break silently after an upgrade.

Composer and autoloading

Introducing dependency management and PSR-4 autoloading to codebases that were built on require_once chains.

Database access

Replacing string-concatenated queries with prepared statements, adding the indexes that were never created, and fixing N+1 patterns.

Security fixes

SQL injection, XSS, insecure file uploads, session handling and password storage. The issues that come up most in older PHP.

Deployment

Getting the application onto a repeatable deploy instead of dragging files over FTP.

How I work on it

Process

Adjusted to the job, but this is the shape it usually takes.

  1. Read the code first

    Before quoting anything I read the codebase and the server it runs on. Estimates made without that are guesses.

  2. Agree the risky list

    We write down what is fragile, what is security-critical and what can safely be left alone. Not everything needs fixing.

  3. Work in small releases

    Changes ship in reviewable pieces so a regression is easy to trace and roll back.

  4. Leave notes behind

    Setup steps, environment variables and known quirks get written down so the next person is not starting from zero.

Questions

Things people ask

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.

Need help with php development?

Tell me the situation and what you have already tried. I read the code and the server before quoting anything.

Get in touch