JOURNAL — 007 · Development
Block Themes vs Classic PHP: What We Actually Build in 2026
Gutenberg won the argument but not every project. An honest engineering answer to which WordPress architecture fits which client — with the maintenance bills to prove it.
Every WordPress proposal now contains the same fork in the road: native block theme or battle-tested classic PHP stack. The community has strong opinions; we have invoices and maintenance logs instead. After migrating eleven client sites across both architectures in the last year, our answer is boringly conditional — and the conditions are what this article is for.
Audit before architecture
Every rebuild that goes smoothly started with an inventory nobody wanted to write: templates in use, plugins with business logic buried inside, integrations with tribal knowledge as documentation. Skipping the audit doesn't save the week — it bills the month.
We export the plugin list, crawl every template, and interview whoever touches the site weekly. The output is a one-page map of what the site actually does, as opposed to what anyone remembers it doing.
Ninety percent of rebuild surprises were knowable on day three. The other ten percent are why timelines have buffers, not excuses.
The launch-week readiness list
- Backups verified by an actual restore, not a green dashboard icon
- Rollback plan rehearsed: one command back to last-known-good
- Error monitoring on production with an owner assigned
- Core Web Vitals re-tested on production hardware, not staging
- 301s spot-checked from the old sitemap, robots and canonicals audited
- The 'who gets paged' list updated and acknowledged before Friday
Technical debt has an interest rate
Nobody feels technical debt on the day it's taken. It arrives eighteen months later as 'a simple change' quoted at three weeks: the workaround that became load-bearing, the plugin forked and now unforkable.
The honest measure is drag per quarter — how much slower is each change than the one before it. When drag doubles, consolidation pays for itself faster than new features.
Refactoring for elegance is vanity. Refactoring to restore change-speed is maintenance, and it's usually overdue before anyone schedules it.
A plugin is a promise made by a stranger. Choose few, choose well.Internal review, 2025
Maintenance is a product
Sites don't decay because of hackers and core updates; they decay because nobody's job is 'keep it excellent.' Updates run until something breaks, then maintenance gets funded retroactively with interest.
The retainer structure that works is small and relentless: weekly updates in staging, monthly regression checks, quarterly performance and uptime reviews, and a human who knows the site answering within hours.
The build-vs-plugin line
Every plugin is a dependency with its own author, roadmap and security record. Our line: if a requirement is core to the business and stable, build it natively; if it's peripheral and moving, rent it.
Custom code is not automatically better — badly written custom code is worse than a mature plugin. The calculus is control over the parts that make you money versus maintenance on the parts that don't.
A healthy WordPress or Shopify build in 2026 is quietly boring: few dependencies, all understood, everything load-bearing owned.
We don't do rescue projects anymore. We do builds that never need rescuing.Humdan Ali, founder
Where to start this week
Open your theme's functions.php and your last three plugin updates. If your team can't explain what either does, architecture choice matters more than tooling choice for you.
Then keep it honest with a short list:
- Every change request returns with a bigger estimate than the last one
- Two plugins conflict and the fix is a third plugin
- Mobile LCP is over 4 seconds and nobody remembers why
- Put the date on the calendar — playbooks without Fridays are just reading
And when the scope outgrows the spreadsheet, that's precisely what our team is for.
Straight answers
How long does a typical WordPress or Shopify build take?
Six to ten weeks for most marketing sites and stores: two for discovery and architecture, three to five for design and build, and one hardening week we refuse to skip. Rushed timelines are available; we just document what you're trading.
Who owns the code and hosting?
You do — repositories, credentials, hosting, everything. Agencies that hold infrastructure hostage are telling you about their retention strategy, not their confidence in their work.
How do you handle deployments and downtime risk?
Versioned releases to staging first, database-free deploys where possible, rollback rehearsed before it's needed. Launches happen mid-week mornings, never Fridays, never unattended.

