WooCommerce agency work: what a store build needs that a site build does not
Quoting a WooCommerce store like a WordPress site is the agency mistake. Orders left the posts table, checkout is a block, and the extensions set the price.
An agency that has shipped twenty WordPress sites will quote a WooCommerce store like the twenty-first. Same admin, same theme layer, same deploy, plus a shop. Then the first migration meets an extension nobody has updated since the order tables changed, and the fixed price stops being fixed.
The difference is not the shop. It is that a store carries transactional data, a payment obligation and a second data layer that a brochure site does not have. Everything below is checkable today against WooCommerce’s own documentation, and most of it is checkable by you rather than by a developer.
The short version
A WooCommerce agency is taking on three things a WordPress agency is not: an order store that no longer lives in the WordPress posts table, a checkout that is now a block rather than a PHP template, and an extension estate where a single unmaintained plugin can block a core feature for the whole site. WooCommerce’s developer documentation states that High Performance Order Storage has been enabled by default on new installations since WooCommerce 8.2, released in October 2023. Before you quote a store, inventory the extensions. That list, not the design, is where the price lives.
Orders left the posts table
For most of WooCommerce’s life an order was a WordPress post, and its details were rows of post meta. That is no longer where a new store keeps them. High Performance Order Storage gives orders their own tables, and WooCommerce’s developer docs are explicit about the consequences: at any time one set of tables is authoritative and the other is a backup, and switching which set is authoritative is not allowed while any orders are still pending synchronisation.
Two things follow, and they are the ones that surprise agencies.
The first is that custom code written against the old structure does not error. It returns nothing. A report, an export, an integration with the client’s accounting system, anything that walked the posts table looking for orders will keep running and keep coming back empty. Nobody gets an alert. Somebody notices at month end.
The second is that this is not opt-in per plugin by accident. WooCommerce’s HPOS recipe book documents how an extension declares itself compatible or incompatible with the custom_order_tables feature, and states that WooCommerce warns users if they try to enable HPOS while any incompatible plugins are active, and flags those plugins on the Plugins screen. So an old subscriptions plugin or a bespoke shipping integration does not just fail quietly. It holds the whole store on the legacy storage until somebody deals with it.
If you are taking over a store rather than building one, that warning screen is the first thing to look at, and it takes about a minute.
The checkout is a block now
The cart and checkout pages used to be a shortcode rendering PHP templates, which is why every WooCommerce theme in the last decade shipped template overrides for them. WooCommerce now ships them as blocks: its store editing documentation has a section on replacing the existing cart and checkout shortcodes with the block versions, and documents a Classic Shortcode placeholder block for going back the other way.
This changes who can change the checkout, which is the part that matters commercially.
- In your client’s favour: field order, messaging, layout and most of what a client asks for after launch become editor work rather than developer work. That is a real reduction in small-change tickets.
- Against it: a customisation that used to be a template override now needs the block APIs, and older payment or checkout-field extensions may only support the shortcode version. That is a compatibility question with a real answer, not a preference, and it has to be asked before the quote rather than after.
Neither route is wrong. What is wrong is discovering which one a store is on during the build.
The extension estate is the quote
On a brochure site, plugins are a maintenance concern. On a store they are the product: payments, shipping rates, tax, invoicing, subscriptions, feeds. So the honest way to price a WooCommerce project is to price the extension list first.
You can check the state of any plugin from the WordPress.org directory yourself, in a browser, without touching the site. The plugin information endpoint returns plain JSON, and you swap the slug at the end of the URL for whichever plugin you are checking. Checked on 27 August 2026, woocommerce itself returns version 11.0.1, last updated 10 August 2026, requiring WordPress 6.9 and PHP 7.4 as a minimum, tested up to WordPress 7.0.4, with a directory figure of 7 million active installations. WordPress core’s own version endpoint reports 7.1 as current on the same day.
That last pair is the useful lesson rather than a criticism: even the flagship extension declares itself tested against a slightly older core. “Tested up to” is a maintenance signal, not a compatibility guarantee, and you read it as a trend across the whole extension list rather than as a pass or fail on one.
The signal that genuinely stops a project is different, and it is the one nobody sees from inside the admin. Query the endpoint for woocommerce-gateway-paypal-express-checkout, the old WooCommerce PayPal Checkout payment gateway, and it does not return a version at all. It returns a closure notice: closed on 9 July 2024, at the author’s request, with the directory stating the closure is permanent.
A closed plugin still runs. It still takes payments. It never offers an update again, and it will never appear in an update report, which is exactly why a store can sit on one for two years with nobody flagging it. That is the class of finding that decides whether a takeover is a week or a quarter, and it costs one URL to check.
For contrast, the same endpoint on a maintained extension gives you the opposite picture immediately: the FOX currency switcher returns version 1.5.1, updated 27 July 2026, tested against WordPress 7.0.4, on 50,000 active installations. Same check, and it is the comparison that tells you something rather than either number alone.
Site project against store project
| WordPress site project | WooCommerce store project | |
|---|---|---|
| Core data | Pages and posts, all in the posts table | Orders in their own tables, with a synchronisation state that has to be settled before storage can be switched |
| What breaks silently | Little. A broken query usually shows on a page | An order query written against the old structure returns nothing, with no error and no alert |
| Checkout layer | No equivalent | Blocks, with a documented Classic Shortcode fallback. Decide which one before quoting |
| Plugins | A maintenance concern | The product itself, and one incompatible extension holds back a core feature site-wide |
| Accounts to transfer | Domain, hosting, DNS, analytics | All of those plus payment gateways, merchant records and tax configuration |
| Cost of being wrong | A page looks wrong | An order is taken and not recorded, or a payment routes to the wrong account |
| What decides the price | Page count and design complexity | The extension list, checked before the quote |
What you can check yourself, and what needs a developer
Worth being clear about the split, because agencies routinely pay for the first half.
You can do these without a developer. Open the WordPress.org plugin information endpoint for each plugin slug and read the last-updated date, the tested-up-to version and whether it returns a closure notice. Open WooCommerce settings and look at the advanced section for the custom data stores screen, which tells you which storage the site is on and whether anything is warning about incompatibility. List the payment gateways and confirm whose company name and bank details each account is in. Ask who owns the domain registrar login. None of that requires code and all of it changes what a project is worth.
These need a developer, and no amount of reading replaces one. Migrating a store from legacy order storage when an extension is blocking it. Rewriting custom reporting or an accounting integration against the order tables. Rebuilding a checkout customisation that only ever existed as a template override. Anything that touches a live payment path, because the failure mode there is money rather than layout.
The line is roughly this: finding out what is true is yours, changing anything that touches an order is not.
What to ask a WooCommerce partner
Six questions, and the answers are short if the partner has done this before.
- Which order storage is the store on today, and if it is the legacy one, what is blocking the switch?
- Which extensions on this site are closed, unmaintained or untested against current WordPress, and what replaces each one?
- Is the checkout on blocks or the classic shortcode, and which are you quoting against?
- Who holds the payment gateway accounts after launch, in writing?
- What happens to the order data if we leave, and in what format?
- Who takes the call when payments fail on a Saturday, and what does that cost?
A partner who answers all six without checking has run a store before. A partner who finds the questions unusual has built shop pages, which is a different job from being responsible for a store.
Where this sits alongside the rest
If the platform decision is still open, Shopify against WooCommerce is the comparison rather than this page. If the store already exists and the question is keeping it running, WooCommerce maintenance covers what a plan actually has to include. If you are choosing who builds it, the supplier shapes worth shortlisting apply to store work as much as to site work, and so do the tests a built site has to pass whoever’s name is on it.
We build and take over WooCommerce stores as a production partner for agencies, under your brand, and we have been doing agency-facing WordPress work since 2008. If you have a store to quote and an extension list you have not read yet, send it over and we will tell you what is in it.