The thesis
WooCommerce ships an account page: a small menu — Orders, Downloads, Addresses, Account details — rendering theme-styled sub-pages. For a store with repeat customers, that page is the front door of the post-purchase relationship, and it is routinely the least-engineered surface of the whole store.
WooAccount began as a thesis: the account area does not need a restyle, it needs to become a portal — an application with its own frame, its own UI system and complete surfaces for everything a customer does after buying. And it must be built on WooCommerce without ever pretending to be WooCommerce: the store keeps the commerce data, the portal owns the experience.
That product now exists and is licensed commercially — live at wooaccount.com, with a public demo running a real store. What follows is the engineering account of how it is built.
The architecture in four decisions
1. A standalone application frame inside WordPress. The portal is its own application layer: the customer experience is a React product UI served within the WordPress environment, with its own routing and state — not a set of shortcode pages. WordPress hosts it; WooCommerce feeds it; the frame is ours.
2. WooCommerce as the only source of truth. Every order, customer record, payment and business rule remains in WooCommerce. The portal reads and writes through the public WooCommerce APIs. It does not copy orders, does not sync customers, does not maintain a shadow database. Two sources of truth drift; one does not.
3. HPOS-native means never touching HPOS tables. WooCommerce High-Performance Order Storage moves order data into dedicated tables. A tempting shortcut is querying them directly — it is also how products break across WooCommerce releases. WooAccount never queries HPOS tables: going through the APIs keeps it correct on both storage backends and across the WooCommerce 9.x–11.x line it supports.
4. REST-first with a lightweight data layer. The product UI talks to a REST API architecture backed by its own small data layer inside the plugin. That gives the front-end a modern application contract (predictable endpoints, testable behavior) while the plugin stays installable on ordinary WordPress hosting — no exotic server requirements.
Fourteen surfaces, one product
The breadth of the account domain is easy to underestimate. As shipped, the product covers: Dashboard, Orders, Payments, Invoices, Wallet, Rewards, Coupons, Support, Downloads, Notifications, Addresses, Account & authentication, an Admin control center, and the Licensing system. The engineering constraint is coherence: each surface has to feel like part of one product — same shell, same interaction model — while each has its own data relationships and edge cases. The support surface ties threads to orders; the wallet and rewards surfaces reconcile against WooCommerce payments; notifications stitch events across all of the above.
Licensing: the commercial infrastructure
Shipping a commercial WordPress product means running licensing infrastructure for machines you do not control. The design:
- Signed activation. License activations return signed responses — a domain cannot trivially forge validity.
- Activation management. Licenses track the domains they are active on; owners can see and manage activations from a control center.
- A 14-day grace window. Domains move and servers go offline temporarily; a short grace period keeps customer sites working through ordinary operational turbulence without opening an unlimited offline hole.
- A public verification API, because legitimate ecosystems (and our own store) need to check a license mechanically.
Security as architecture
Customer-facing commerce tooling inherits the threat model of the store beneath it, so the security posture is structural: ownership checks on every customer object; WooCommerce capability enforcement rather than a parallel permission scheme; documents routed through safe endpoints rather than exposed paths; downloads controlled and validated; licensing responses signed. None of this is exotic — the discipline is applying all of it, everywhere, including the surfaces that feel minor.
What shipped
WordPress 6.7+, WooCommerce 9.0–11.x, PHP 8.1+, HPOS-native, RTL and LTR. Documentation generated from the codebase so it cannot silently drift from shipped behavior. A live demo store. And the constraint that shaped everything: WooCommerce stayed the source of truth from the first commit to the current release.
What the project demonstrates
Not every lesson generalizes, but three do. Authority boundaries matter more than feature lists — the product works because it never competes with the platform it extends. Application-grade architecture is achievable inside WordPress — when the team treats WordPress as a platform rather than a page template. Commercial infrastructure is part of the engineering — licensing, grace windows and verification APIs are product features, not afterthoughts.
If your WooCommerce store needs this class of account experience — or an engineered extension of your own — that is squarely the kind of work we do.