Building a WooCommerce store
WooCommerce is not e-commerce software, it is a plugin adding selling to a publishing system. That sentence explains most of it: editorial freedom, an easy market for help, cost shifting towards extensions, and the limits that appear once the catalogue gains volume.
The data model, and why it matters
Historically a WooCommerce product is a WordPress content item: one row in wp_posts, and everything else — price, stock, weight, SKU — in wp_postmeta, one meta per row. That choice makes the model endlessly extensible: any plugin adds its field with no migration. It also makes some queries expensive, because filtering on three criteria becomes several joins on one table.
Since WooCommerce 8.2 orders have their own tables — high-performance order storage, usually called HPOS — instead of living in wp_posts as well. It is a genuine gain on shops accumulating tens of thousands of orders, and it is the first setting to check on a fresh install, because some older plugins do not support it.
The practical consequence is simple: WooCommerce does not fall over on product volume, it falls over on the number of plugins listening to every page render. A WooCommerce performance problem is almost always a plugin inventory problem.
The budget of a WooCommerce store
- Plugins, on annual subscription. Advanced shipping, bookings, subscriptions, custom fields, forms: each brick has its publisher, its licence and its own release rhythm.
- The page builder, if you take one. It makes layout self-service, and it becomes a dependency you cannot leave without rebuilding the pages.
- Hosting, less demanding than PrestaShop at first, but it must allow an object cache and real scheduled tasks rather than cron fired by visits.
- The child theme, mandatory the moment you touch a template. Editing the parent theme directly is scheduling the loss of your work at the next update.
- Maintenance. WordPress updates a lot, often, and two plugins crossing badly break a checkout page without warning.
- Security. It is the most targeted platform for bots, and one weak administrator account is enough to lose everything.
How I set up a WooCommerce store
-
Count the plugins before installing one
I start from the list of expected functions and look for the shortest combination, writing thirty lines rather than installing a two-thousand-file plugin for one extra field. Every plugin removed is one update less and one potential conflict less.
-
Turn on high-performance order storage
On a fresh install I enable it from the start and check every checkout plugin declares compatibility. Switching after two years of orders is possible, but it is a migration, with its window and its backup.
-
Put a child theme in place immediately
Even when no customisation is planned on day one. The child theme costs ten minutes up front and prevents the “why did my changes disappear” question six months later.
-
Settle tax and shipping before the catalogue
Shipping is the leading source of anomalies on this platform: shipping classes, zones, stacked conditions. I validate them on sample baskets before a thousand products make testing unreadable.
-
Replace the pseudo-cron with a real one
Firing tasks from visits is fine on a content site, not on a shop where reminders, synchronisations and subscription expiries depend on actual clock time.
Related pages
-
WordPress and WooCommerce developer
What I do on the platform, from a fix to a bespoke extension.
-
Custom WooCommerce extension
When no market plugin fits, and what the development costs.
-
Creating a WordPress child theme
The method, and why it is the first thing to do on a fresh install.
-
Slow WooCommerce store
The real causes of slowness, almost always tied to the plugin estate.
Frequently asked questions
Is WooCommerce free?
How many plugins is reasonable?
Can I start from an existing WordPress brochure site?
Do I need a page builder?
Does WooCommerce cope with a large catalogue?
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.