WordPress is not fashionable. It runs forty percent of the web.
We've built and maintain a family of plugins — security firewalls, backup systems, activity logs, an AI-powered auto-blogging tool, uptime monitors. They ship real production workloads. A few things that carry over to any long-lived codebase.
Convention before cleverness
Every plugin in our stack follows the same layout. Singleton main class. Admin code in admin/class-*-admin.php. Serialized settings array in wp_options. Database tables created via dbDelta. Activation and deactivation hooks registered at the top level.
When you have seven plugins, boring is a feature. New work starts with a copy of the template and diverges only where it has to. The reliability comes from the sameness.
License infrastructure is product infrastructure
If you sell plugins, the license validator, the caching layer, renewal flows, and the auto-updater are not secondary concerns. They are the product.
We run our license server with the same discipline as customer-facing code — rate-limited, cached in transients with a day-long TTL, monitored for downtime. When it breaks, every plugin we've ever shipped stops activating. That kind of coupling needs to be treated with real care.
Caches will lie to you
LiteSpeed. HAProxy. Browser cache. CDN. wp-options transients. Each of them, at some point, will serve stale data during a deploy and make you question your sanity.
Instrument every layer. Know which one is lying when something looks wrong in production. A twenty-line logging plugin that writes cache hits and misses has paid for itself more times than we can count.
Small is shipping-ready
Our smallest plugin is under a thousand lines. It does one thing. Its entire admin interface is a single toggle. It has been in production for more than a year and has never required a hotfix.
WordPress rewards the kind of software you don't notice. We are trying to make more of that — and to apply the same discipline to the WordPress engineering work we take on for clients.