The Embroidery Shed: A WooCommerce Rebuild

The Problem

The Embroidery Shed is a Chesterfield business that has been embroidering workwear since 2017. It was already successful. The website was not the reason for that success — it was the tax on it.

Ross was spending time and energy he did not have on hacks, downtime, slowness, and a shop that never quite looked the way he wanted the brand to be seen. The store worked, but it worked despite the platform rather than because of it.

Underneath, the WordPress install had accumulated the usual decade of good intentions. Two page builders. Two SEO plugins. Two security suites. Forty-five active plugins in total, plus a caching plugin that could not do its job because of what was running alongside it.

One detail sums the whole thing up. A bespoke plugin written for the site called session_start() on every single request. That sets a PHPSESSID cookie header on every response, and nginx will not cache a response that sets a cookie. A single line of well-meaning PHP was silently switching off the entire caching layer for every page and every API call on the site. Nobody had done anything wrong, exactly. It had just never been looked at by someone whose job it was to look.

There was also an inherited compromise to clean up. It predated the current hosting and had woken up, so we dealt with that alongside the rebuild as a separate piece of work.

Why Revitt

Ross did not need a lecture about replatforming. He needed the shop to stop costing him.

A full move to another platform would have meant migrating the operation and retraining a team that already knew exactly how it wanted to run products, orders and fulfilment. The back office was not the part that needed replacing.

So we did the opposite. We kept the engine and replaced the bodywork.

The Mullet Shop

The technical term for this is "headless". We prefer "the mullet shop" — custom in the front, Woo in the back.

In plain English: the shop your customers see is a separate, purpose-built application. The system your team logs into to manage products, orders, VAT, shipping, and fulfilment is still WooCommerce, still WordPress, still exactly where they left it.

The customer-facing side gets to be as fast and as brand-specific as a bespoke build, because it is one. The operational side gets to stay boring and familiar, because nobody should have to relearn their own job to get a faster website.

What We Built

A completely custom storefront. A Next.js application in front of the WooCommerce Store API, built around The Embroidery Shed's actual catalogue: 23,006 products and variations, garment colour groups, size rules, quantity price tiers, and VAT that has to display both ways depending on whether a trade customer or a member of the public is looking.

Forty-five plugins down to five. The remaining set is WooCommerce, Redis Object Cache, the WooCommerce Stripe Gateway, and two small first-party plugins we wrote. Every third-party plugin is pinned by SHA-256 checksum, so a compromised update cannot quietly install itself. Everything else — the page builders, the duplicate SEO stack, the duplicate security suites, the caching plugin that could not cache — is gone. About eighty-four unused database tables went with them.

The embroidery configurator, rebuilt properly. The four-step ordering journey — colours, sizes, decorations, customer logo upload — was the most valuable thing on the old site and lived in the most fragile plugin. We ported it into first-party code with the upload flow bound to the cart token, so one customer's artwork cannot be reached from another customer's session.

Search that understands what people mean. Product and content search runs on Meilisearch with hybrid retrieval: keyword matching blended with AI embeddings, so "something warm for the lads outside" finds fleeces. If the embedding service is unavailable, search silently degrades to keyword mode rather than breaking. None of it runs inside WordPress, which means WordPress upgrades can never break search.

Analytics the business owns. We built first-party, cookieless analytics so The Embroidery Shed doesn't depend on Google Analytics to understand traffic and customer value. It derives a per-day rotating pseudonymous visitor hash rather than storing identifiers, honours Do Not Track and Global Privacy Control, and prunes its own data after ninety days. It reports traffic, channels and customer lifetime value from real order data, with AI assistants separated as their own acquisition channel.

Hosting with no public front door. The server has zero inbound ports open. Traffic arrives through an outbound-only Cloudflare tunnel; the origin binds to loopback and nothing else. Containers run read-only, PHP runs as a non-root user with no capabilities, and WordPress cannot modify its own files. Releases are immutable and deployed blue/green with health checks and automatic rollback to the last known-good version.

Proving It Works

Commerce is where "it looks fine" is most dangerous, so we certified it rather than clicked through it.

Twenty-one order scenarios are placed automatically against a staging copy of the real store: standard, zero-rated and mixed VAT baskets, the £99.99/£100.00/£100.01 boundary in both VAT display modes, ten coupon types, pickup and delivery, a seven-slot bundle with uploaded artwork, and a duplicate checkout replay to prove the same order cannot be placed twice. Seven WooCommerce transactional email paths are asserted by message type and order ID on the same run.

Separately, we proved we could get the business back. A full backup was restored into an isolated environment and checked byte by byte: 164,736 upload files totalling 3.13 GB, 164,604 images with zero invalid file signatures, 478 orders, and every database integrity check passing. Backup to verified restore took two hours and twenty-seven minutes. Production deploys are gated on that drill being recent — if the restore proof goes stale, the deploy is refused.

Results

• 45 active plugins reduced to 5 — with all three third-party plugins pinned by checksum, and roughly 84 unused database tables removed.
• Mobile Lighthouse performance on the shop page went from 88 to 99, with largest contentful paint down from 3.81s to 2.15s — and the homepage scores 100. These are lab measurements, not field data.
• Total blocking time fell from 1,340ms to 30ms once we removed around 2,865ms of third-party main-thread scripting that was being injected into every page.
• Warm pages return in 36–57ms at the edge, and a category API call that took 306ms cold now returns in about 2ms from cache — the cache that could not work before.
• Zero public inbound ports — the origin is unreachable from the internet except through an outbound tunnel, and the admin is gated behind Cloudflare Access.
• 21 certified order scenarios and 7 transactional email paths exercise real VAT, shipping, coupon, bundle and replay rules as part of commerce certification.
• A proven two-and-a-half-hour path from backup to verified restore, enforced as a deploy gate.
• The WooCommerce back office is unchanged — the team manages products, orders and fulfilment exactly as it did before.

"I had spent far too much time battling plugins, visual editors, and one-off fixes just to keep the store running. We still manage products and orders in the same familiar WooCommerce back office, but the shop itself is faster, clearer, and properly engineered. I can sleep easier knowing the important bits have been taken care of."

— Ross, The Embroidery Shed

Takeaway

Most WooCommerce shops that feel slow aren't slow because WordPress is bad. They are slow because years of sensible local fixes have accumulated into a system nobody has been paid to simplify. The answer isn't automatically a replatform. It is to find what is costing the shop, remove it, and put something deliberate in front of the part that still works.

Ross keeps WooCommerce, the business data, the hosting and the code. The team keeps the back office it knows, while the customer-facing side can now be improved without dragging the operational system through every change.

The work is still moving. Mobile product pages are being tuned, and reputation recovery from the old compromise takes longer than the clean-up itself, but the foundation is now something worth building on.

Not every shop needs this kind of rebuild, which is why we have written about when a custom WooCommerce storefront earns its keep. If yours is costing more attention than it earns, read about our custom WooCommerce storefront service or send us the store URL.