Where our PHP work happens
PHP's reputation is about fifteen years out of date. Modern PHP has proper types, a good dependency manager, and real performance. The reason it still gets a bad name is that so much of the PHP in the world was written before any of that existed and never updated.
That gap is where our PHP work sits. A theme with business logic scattered through a two thousand line functions file, a plugin patched in place so updates would overwrite it, and a PHP version two releases past end of support.
WordPress theme and plugin development
Custom post types, fields, blocks, and the small plugins that keep site-specific logic out of a theme so it survives a redesign.
WooCommerce customization
Checkout adjustments, shipping and tax rules, and integrations with fulfillment or accounting, done through the supported hooks so an update does not undo them.
Version and dependency upgrades
Getting a site onto a supported PHP release without breaking the plugins that assumed the old one. Running an unsupported PHP version means known vulnerabilities with no patches.
Legacy takeovers
Laravel, Drupal, and hand-rolled PHP applications that need someone to keep them alive while you decide what happens next.
When PHP is the right call, and when it is not
Good fit: you are already on WordPress
If your site runs on WordPress or WooCommerce, PHP is not a choice you are making. It is the language your site is written in, and the right move is to write it well.
Good fit: cheap, plentiful hosting
PHP runs anywhere for very little money. For a small organization with a tight budget, that is a practical advantage worth naming.
Not our default for new applications
When someone needs a custom application from scratch, we build in Ruby on Rails. That is about our depth, not a judgment on the language. If you have a PHP team who will maintain it, build it in PHP.
Watch out: customization in the wrong place
Editing plugin files directly, or putting business logic in a theme, guarantees that an update or a redesign erases it. We move that code somewhere it can survive, which is often the first thing we do on a rescue.
Questions we get about this
- Should we start a new project in PHP?
-
If you already run WordPress or WooCommerce, you are on PHP and the right move is to write it well rather than fight it. If you have in-house PHP developers who will own the result, build it in PHP.
If neither is true and you are starting a custom application from scratch, we would build it in Ruby on Rails, because that is where our depth is. Modern PHP is a perfectly good language. This is about who will maintain the code, not about the language.
- Will you maintain a site you didn't build?
-
Yes, often. Our retainer practice started largely with sites built by other teams. We'll do a short technical and accessibility audit before the retainer starts so we both know what we're working with.
- Is WordPress secure enough for a business website?
-
Yes, if it is maintained. WordPress core itself is not the usual weak point. The openings come from plugins and themes that have gone months or years without an update, and automated scanners look for exactly those known versions.
On a retainer we patch core, plugins, themes, and the PHP version on a schedule, test on staging first, and keep the plugin list short on purpose. If nobody is going to do that work, we would steer you toward a hosted platform instead.
- Can you take over a custom application someone else built?
-
Sometimes. We need read access to the codebase first. Once we've looked at what's there, we can scope what it would take to stabilize it and continue the work. Sometimes the right path is to keep going on what exists. Sometimes it's a rebuild. We'll tell you which, and why, before any work starts.
Have PHP nobody has touched in years?
Old code is not automatically bad code, but unsupported versions are a real risk. A free consultation will tell you what you are running, what is exposed, and whether it is worth maintaining or worth replacing.