After working on multiple WordPress projects (agency and product), we kept running into the same pattern:
Not bugs. Not plugin issues. Structural problems. The recurring problems
Blocks don’t scale. Every developer implements them differently Design systems decay. Tokens exist but nothing enforces them Performance becomes a post-build activity Junior developers unintentionally break global consistency Every project starts from scratch again Maintenance never actually ends
What we tried
Guidelines, code reviews, naming conventions, documentation: None of it held.
Because the problem wasn’t discipline. The problem was lack of enforcement.
What we changed: Instead of adding more process, we asked:
What if WordPress simply didn’t allow inconsistency in the first place?
That led us to build an internal system, now called wpTruss, with a few hard constraints.
- Blocks must pass validation before they exist
We added a Block Validator with 12 rules. No hardcoded colors. Must use tokens
No global CSS leakage. Must be scoped. Required structure enforced. No almost correct blocks allowed
If it fails, it does not register.
Result
You don’t review blocks anymore. The system rejects bad ones upfront.
- Tokens are not optional
We implemented a Token Registry: colors, spacing, typography, radius and shadows Blocks do not store values. They reference tokens. So when a client says Change brand color
You change one value and the entire system updates instantly.
- Structure over theme
We removed the idea of a theme. Header is a block. Footer is a block. Templates are block compositions
Everything is built using the same system. No theme lock-in. No builder dependency. Just structured blocks assembling the entire site.
- Elements are centralized
Instead of every block redefining headings, buttons, and images, we created an Element Registry in JS.
Each element: resolves tokens, enforces consistency, behaves predictably everywhere. So a button is not 17 variations across blocks. It is one system-controlled element.
- Performance is not optimized. It is produced
We built an Asset Bundler that: loads CSS and JS per page, only what is used, combines and minifies, automatically, injects proper image attributes, defers JS by default, We did not build this for PageSpeed.
But the output consistently hits:
95+ out of 100 without any performance plugins
Even with:
WooCommerce, AJAX, infinite scroll microstore blocks,
- Blocks became more than content
We started building micro-app blocks.
Example
A single block that: loads products, infinite scroll, AJAX cart, cart updates, checkout flow(default woocommerce)
This is essentially a mini storefront inside one block.
It still scores 95+. What this changes in practice, Rebrands take minutes instead of days, New projects import a system instead of rebuilding it, Junior developer risk is structurally eliminated, Performance is no longer a separate phase, Maintenance is close to zero, Or more bluntly, The system removes the need for being careful.
Why we are sharing this now
Over the past few weeks, we have been discussing parts of this problem here:
block scaling, validation, design entropy, WordPress as an operating layer
Those discussions led to this system.
If you want context, here are the earlier threads:
https://www.reddit.com/r/Wordpress/comments/1rckzzf/rethinking_wordpress_as_an_operating_layer/
Where it is now, This is not a concept anymore.
It is running. Who this is for: Not beginners. Specifically: agencies, product teams, developers working with Gutenberg at scale
If you have ever said: Why does every project slowly fall apart
This is our answer.
Open to questions
Happy to break down: validator rules, architecture decisions, tradeoffs, where this might not fit
No fluff. Just what we have learned building it.