WooCommerce development

A store is a transaction processor that happens to have pages, and four things about it break the ordinary WordPress routine. The rollback is not free, because restoring a backup taken before an update also discards every order, payment and stock movement recorded since, and WooCommerce keeps those in dedicated database tables rather than alongside your pages. The failure is silent, because a broken checkout renders perfectly and customers who cannot pay do not file bug reports. Your customisations go stale on a schedule you do not control, because WooCommerce updates its own templates while the copies your theme keeps stay frozen at whatever version they were written against. And since 31 March 2025 the checkout page carries a PCI DSS duty of its own, under requirements 6.4.3 and 11.6.1, which means every script loading on it has to be authorised and monitored. A developer who has only built brochure sites will do everything correctly and still miss all four.

Almost always the database and the host rather than the front end. WooCommerce accumulates orders, sessions, revisions and logs in WordPress tables, and every uncached page load queries them, so a store that was quick at 300 products behaves differently at 5,000. High-Performance Order Storage, the default for new installations since WooCommerce 8.2 in October 2023, moves orders into their own tables and helps considerably, but it does nothing for a host that cannot meet the current floor of WordPress 6.9, PHP 8.3, MySQL 8.0 and 256 MB of memory. Past a few thousand products, product search is usually the next thing that has to come off the database entirely. We audit before we quote, because the answer differs per store and a caching plugin is rarely it.

It depends on what is already plugged into your checkout, and no deadline is forcing the decision. WooCommerce has stated it has no plans to remove the classic shortcodes and has committed to giving notice if that ever changes, so anyone telling you to migrate this quarter is manufacturing urgency. What is true is directional: new checkout features are being built for the block version, so staying on shortcodes gradually costs you options rather than breaking anything. The risk in migrating is specific and testable, and it is payment gateways and checkout-field plugins that have not caught up, plus analytics that read the old markup. We test every extension against the block checkout on a staging copy first, and if one is not ready we say so before the migration rather than after it.

Sometimes, and we will say so, because we build on both. The honest split is this. Shopify carries the hosting, the security and the payment compliance for you, and charges for it in fees and in flexibility. WooCommerce hands you the code and the data and expects somebody competent to look after them. If you have no technical capacity and no appetite to buy any, Shopify is the lower-risk choice and we have moved businesses onto it. If your store has requirements that do not fit a template, or you want your product data and your customer list in a database you control, WooCommerce is usually cheaper to run and always more flexible. We have talked clients out of both, which is the only reason our answer to this is worth anything.

Two things that rarely appear in a WooCommerce quote. VAT is the obvious one: the UK sits outside the EU One Stop Shop, so selling to EU consumers brings an OSS or IOSS reporting obligation that core WooCommerce does not handle on its own. It becomes an extension decision, with subscription renewals as the sharp edge. The less obvious one is accessibility. The European Accessibility Act has been in force since 28 June 2025, it names eCommerce explicitly, and it applies on the basis of who you sell to rather than where you are registered, so a UK store selling to EU consumers is in scope. The standard it points at is WCAG 2.1 AA plus a published accessibility statement. We build to WCAG 2.2 AA as standard, not as a paid extra.

We scope before we quote, because the number is set by how many moving parts the store has rather than by what it sells. Payment methods, shipping and tax integrations, template overrides, the plugin count, and whether the product data lives in WooCommerce or in another system are what drive the effort. You will find build and maintenance prices published as a function of store revenue, and that is value-based pricing wearing a cost estimate as a disguise: two stores with the same technical footprint need the same work whether one turns over 50,000 or five million. Our cost calculator gives an honest range for a project of your size, including the running costs that a quote for the build alone leaves out.