WooCommerce Developer: How to Choose the Right One (and Avoid Costly Mistakes)

WooCommerce runs about a third of the world's catalogued online stores — by store count, since its share drops below 20% if you look only at the top million retail sites. That popularity has a downside: almost any WordPress developer now presents themselves as a WooCommerce developer, even though handling a catalogue, multi-country VAT and a payment funnel has little in common with assembling a brochure site.

The gap in outcomes is wide. A badly built store does not fail on launch day — it collapses six months later, when the catalogue reaches 2,000 SKUs or the first traffic spike arrives. Here is how to recognise, before signing, someone who can go the distance.

Why a specialist rather than a WordPress generalist

A brochure site serves near-static content. A WooCommerce store runs database queries on every page, manages cart sessions, syncs stock, applies tax rules and talks to a payment provider. These are two different jobs.

The difference rarely shows at delivery. It shows as the catalogue grows: a 200-product store forgives a lot of shortcuts, a 5,000-SKU store forgives none. Unindexed queries, badly modelled variations and plugins loading on every page turn into minutes of load time.

What WooCommerce actually adds to WordPress

WooCommerce is a plugin, but it installs a complete application inside WordPress: two content types (the product and the order), three product taxonomies, a session-backed cart, a tax engine and a multi-step checkout. None of that exists on a brochure site.

The practical consequence: you do not customise a store by editing templates, you adapt it by hooking into the actions and filters WooCommerce exposes, from a purpose-built plugin or a child theme. A developer who ignores that mechanism edits files the next update overwrites, and the store then stays frozen on an outdated version to keep those changes alive.

Five objects come up in almost every project. Your supplier should be able to name them without hesitating.

• The variable product — one listing, several variations each with its own price, stock and SKU. Modelled badly, it makes the catalogue impossible to filter.
• Global attributes — reusable across products, they are what powers store filters. Local attributes filter nothing at all.
• Stock handling — decrementing at order or at payment, holding stock during checkout, partial shortages on a multi-item order.
• Order statuses — each one triggers emails and records. Customising them is routine, inventing them outside the API is a source of outages.
• Order storage (HPOS) — orders now live in dedicated tables rather than in wp_posts. Older plugins have not all followed.

These are precisely the places where a badly built store starts to cost money. One question is enough to test the ground: "how do you handle a stock-out on a single variation of a variable product?"

Six skills to check before you sign

Beyond knowing WordPress, here is what actually separates someone who can deliver a store that lasts.

• WooCommerce hooks — changing behaviour through add_filter rather than editing core or the parent theme. This is what makes updates possible without breaking everything.
• Catalogue modelling — telling variable products, grouped products and global attributes apart. A mistake here is paid for over years.
• Database performance — understanding why wp_postmeta becomes the bottleneck, and when to move to dedicated tables or HPOS.
• Payments and VAT — SCA, 3D Secure, intra-EU VAT, the OSS one-stop shop. These are regulatory matters, not options.
• The checkout funnel — being able to measure and fix cart abandonment, not merely report it.
• GDPR applied to ecommerce — order retention periods, consent, processors.

Nobody is excellent at all six. What matters is that your contact can say where they are weak and how they compensate: an accountant for VAT, a specialist host for performance. The worrying answer is the one that claims to cover everything.

Questions to ask in the interview

None of these require technical knowledge to ask, but the answers are highly revealing.

• "How many stores do you have live today, and what is the largest by SKU count?"
• "How do you handle WooCommerce updates on a site you have customised?"
• "What happens if I want to change supplier in two years?"
• "Do I own the site outright, code and access included?"
• "What is your plan if the store goes down on a busy Saturday?"
• "Which metrics will tell us the project succeeded?"

Reading an ecommerce portfolio without being technical

A store portfolio is easy to dress up: screenshots prove nothing, a mockup even less. Five checks are enough to rule out anyone who has never gone beyond a brochure site with a "shop" page.

• Ask for live store addresses, not visuals. Check that you can add to cart and reach the payment page.
• Open a category page with a filter applied, not the homepage. That is where queries multiply, and that is the page Google judges.
• Look for a product with variations — size, colour, volume. A developer who has only shipped simple products has not met half the real problems.
• Test internal search and price sorting on a full catalogue. Plenty of stores fall apart exactly there.
• Ask how long the store has been running and who has updated it since. A two-year-old store still on current versions beats a recent rebuild.

These checks do not replace a code audit, but they change the nature of the conversation. A developer who has shipped real stores answers with numbers: SKU counts, order volumes, server response times. Someone who has not answers with design vocabulary.

The integrations you must price separately

The biggest source of budget overrun is not the design, it is connecting the store to the rest of the business. A quote that gives one global price without itemising these lines will reveal the real bill mid-project.

Two details move these numbers by a factor of three. First, the direction of the sync: does the ERP overwrite the catalogue, or the other way round? Two-way costs considerably more. Second, the frequency: stock refreshed overnight is enough for many businesses, while real time becomes a project of its own.

The case where you should not integrate deserves saying out loud: below twenty orders a month, re-keying by hand costs a few minutes per order, while an ERP sync costs several thousand pounds and has to be maintained on both sides.

Why 3,000 SKUs behave nothing like 20 pages

On a brochure site, a page is cached and served as is. On a store, the cart, per-customer pricing, availability and filters differ from one visitor to the next: classic caching cannot absorb everything, and that is why a store needs a different architecture.

The tipping point sits rarely below a thousand SKUs. Past that, a filtered category page can fire hundreds of queries against product metadata, and server response time goes from 200 milliseconds to several seconds.

Here is what an experienced developer puts in place, and what the quote can require.

• Page caching that excludes the cart, the customer account and checkout, rather than a blanket cache that eventually shows one visitor another visitor's basket.
• HPOS order storage enabled, and database indexes on the columns that are actually queried.
• Product images in WebP or AVIF, sized for the category thumbnail rather than for the product page.
• Filtering that queries lookup tables instead of scanning metadata on every click.
• A before-and-after measurement on a real category page.

Real budgets in 2026

The ranges below reflect the UK market for custom work, not theme assembly.

A quote well below these ranges rarely funds the invisible work: catalogue modelling, order testing, tax compliance. That work still gets done — by you, or by the next supplier.

Broken down by the day, a WooCommerce specialist charges between £340 and £590. Below £290 you are paying a theme integrator: that can be enough for a simple store, but not for a carrier integration or a fix in the checkout flow.

Maintenance, security and code ownership

WooCommerce ships fixes regularly, and every plugin follows its own release rhythm. On a store, a failed update does not break a layout: it stops people paying. So the question is not whether you take a maintenance contract, but which one.

The line to put in writing is the response time when checkout is broken: a store down on a Saturday costs a day of revenue, and a reply promised "within 48 working hours" protects nothing. Ask as well how a restore actually runs: a backup that has never been restored is a backup of unknown value.

What the quote must say about ownership

A great many disputes start here. A site can be delivered without you owning it in any practical sense: hosting in the supplier's name, paid plugins under their licence, code never version-controlled. Four lines close the subject.

• The custom code is assigned to you, with the rights to use and modify it.
• Hosting, the domain and the payment provider account are opened in your name.
• Licences for paid plugins are in your name, renewable without the supplier.
• You have access to the Git repository and to a full exportable backup.

Without those guarantees, handover to another supplier is paid for in days of archaeology, sometimes several thousand pounds.

Red flags worth walking away from

These are not cosmetic details. Each one maps to a dispute that has already happened, and none is easy to fix once the contract is signed.

• No live store to show, only mockups.
• The quote mentions neither acceptance testing nor migrating the existing catalogue.
• Hosting and domain are registered in the supplier's name.
• No mention of backups or a staging environment.
• VAT and legal notices are deferred to "your accountant".

FAQ — Hiring a WooCommerce developer

Is WooCommerce suitable for a large store?

Yes, up to several tens of thousands of SKUs, provided the database is modelled properly and high-performance order storage (HPOS) is enabled. The practical ceiling almost always comes from the quality of the build, not from WooCommerce itself.

Freelancer or agency?

An experienced freelancer is enough for a standard store and costs less. An agency makes sense when you need guaranteed continuity of service, ERP synchronisation, or contractual uptime commitments.

What is a WooCommerce developer's day rate?

Between £340 and £590 a day for a genuinely ecommerce-focused profile. Below £290 you are usually hiring a theme integrator rather than a developer able to change how the store behaves.

Can you migrate from Shopify to WooCommerce?

Yes. Migrating the catalogue, customers and order history is standard work. The point to watch is preserving product URLs with 301 redirects — without them, the store loses the search rankings it had earned.

How long does it take to build a WooCommerce store?

Allow 4 to 6 weeks for a simple store whose catalogue is already clean, and 2 to 5 months as soon as an ERP has to be synchronised or marketplaces fed. The timeline depends mostly on you: product copy, photography and terms of sale hold up the schedule more often than the development does.

How do I judge technical skill without being able to code?

Open a filtered category page on one of their live stores and measure it in PageSpeed Insights on mobile. Then ask how the customisations were built: a dedicated plugin or a child theme with hooks beats a page builder.

Sources

• WooCommerce — High-Performance Order Storage — why orders no longer live in wp_posts
• WooCommerce — Hooks and filters reference — what you override without touching core
• WooCommerce — Variable products — modelling variations and attributes
• WooCommerce — Setting up taxes — tax rules and per-country rates
• WordPress — Backups and restore — what a backup plan must cover
• web.dev — Core Web Vitals — LCP, INP, CLS thresholds
• Service-Public — Intra-EU VAT number — invoicing obligations inside the EU