PHP 8 Engineering and Modernization (Non-Laravel)

Most PHP in production is not Laravel. It is Symfony, WordPress multi-site, CodeIgniter, a legacy in-house framework that predates Composer, or a bespoke service that someone shipped in 2014 and never revisited. I do senior PHP 8 engineering on what you have rather than selling you a rewrite of what you wish you had.

The work is modernization, security, integration, and performance — the four things that decide whether an inherited PHP application is an asset or an outage waiting for a quiet Friday.

What I ship

• Version uplift, PHP 5 or 7 to PHP 8. Typed properties, readonly properties, enums, match expressions, and removal of deprecated extensions. The application behaves the same on the outside and is supportable on the inside.
• Security and dependency audits. composer.lock review, CVE triage against known-vulnerable versions, static analysis with SAST tooling, and authentication and session hardening against current OWASP guidance.
• Custom backends and integrations. REST and GraphQL adapters, webhook receivers, queue consumers, and ETL between SaaS systems that were never designed to talk to each other.
• Performance work. Opcache and JIT tuning, N+1 query elimination, index review, HTTP caching, and the boring profiler-driven work that takes a page from two seconds to two hundred milliseconds.
• Test-coverage uplift. PHPUnit on legacy code, starting with the parts most likely to break and the parts most expensive when they do. Characterization tests before refactors; regression tests after.

Where it fits

PHP 7.4 applications running out of host support

Symfony 4 on PHP 7.4. WordPress multi-site on PHP 7.4. A bespoke framework on PHP 7.2 that the hosting provider has been emailing about for six months. Most PHP 7.4 to PHP 8.x uplifts land in four to eight weeks, depending on how much of the codebase depends on now-removed extensions and how honest the existing test suite is.

Inherited applications with no documented architecture

The previous developer left. The repository has a README that says "TODO." The application earns money. I deliver a written architecture review, a documented data model, a dependency map, a 90-day modernization plan with effort estimates, and a prioritized risk register — before any code changes.

Bespoke backends needing SaaS integration

A working application needs to talk to a billing provider, a CRM, a logistics API, or an internal data warehouse. I write the integration as an isolated module with its own tests, its own logging, and its own failure modes, so the integration can change vendors without changing the rest of the application.

Why modernization, not rewrite

A rewrite recreates every bug you fixed in the original system and several new ones, costs more than the modernization, and ships later. Focused PHP 8 uplift removes the end-of-life and security exposure, restores host-vendor support, and leaves the application running with the business logic intact. The rewrite conversation is sometimes the right one — but it should follow a written assessment, not precede it. Patterns and post-mortems from this work are collected in the research notes.

PHP still runs the majority of public web server-side workload. Buyers need senior engineering on the codebase they operate, not a sales pitch for a different stack.

How I work

Every engagement starts with a written inventory: PHP version, framework version, extension list, composer.lock contents, hosting target, test coverage, and known pain points. I deliver the inventory and a phased plan before touching the codebase. Phases are scoped to ship value at every checkpoint, not at the end. The principal carrying the work — background, certifications, and bias — is described on the about page.

I work directly in your repository on a branch. Changes ship as reviewable pull requests with descriptions a non-PHP reader can follow. Test runs are part of the PR, not promised for later.

Engagement model

Audit-only engagements run one to three weeks and deliver a written report with a prioritized backlog. Modernization engagements run four to twelve weeks depending on scope, with weekly demos and a clear cutover plan. Integration work is scoped per integration with fixed-price options where the third-party API documentation supports it.

Engineering supports the primary AI consulting practice. If your modernization includes adding LLM features or AI-assisted developer workflows, the security review for that surface is in scope on the same engagement.