Skip to content
Back to case studies
Web appsWeb Development

Pewes Energy

pewesenergy.com
Pewes Energy
PEWES ENERGY is a headless WooCommerce storefront we built for ourselves, to answer a question we kept being asked in sales calls: what does WordPress e-commerce actually look like when nobody is fighting a theme, and how far can it be pushed before something breaks. It is a real shop. Thirty eight products across four ranges, a working cart and checkout, customer accounts, invoices, subscriptions, a reseller programme and a dropshipping API. Payments run against Stripe in test mode and nothing is dispatched, but every other part of it is finished rather than mocked.

The brief we gave ourselves

Three rules, set before a line of code was written. Nothing is a placeholder. If a screen exists, it works. You can register, buy, download a sequentially numbered invoice, start a subscription, change it, and cancel it in one click. Demos that fall apart on the second click are worse than no demo. Speed is a property, not a pass at the end. The site had to be fast while carrying a real three dimensional product model on the home page, because anybody can be fast with a static page and a hero image. WordPress stays in charge of content. Every headline, description and meta title on the site is edited in WordPress by a person. The split removes rendering, not the editor.

What we built

  • Catalogue and filtering. Four ranges, filtering across several attribute taxonomies at once, quantity pricing that makes a case cheaper than a single can, published as one source of truth so the shop, the cart, the feeds and the API all quote the same number.
  • Cart and checkout. Optimistic quantity changes, Stripe Elements on the storefront, and orders created as pending until a webhook confirms payment, so an abandoned tab never loses an order.
  • Accounts. Orders, wishlist, addresses, reviews, invoices generated in the browser, notifications, and a full password reset flow owned by the storefront rather than by wp-login.
  • Subscriptions, built rather than bought. Any mix of cans, a delivery date chosen by the customer, ten percent off, one click to pause or cancel. Stripe handles the recurring charge; each cycle lands as an ordinary WooCommerce order.
  • A reseller programme. Five trade levels, a booking system for the qualifying sales call with database enforced slot locking, and automatic promotion of the account onto its discount tier when the call is done.
  • A dropshipping API. Five documented endpoints with idempotency keys, per partner pricing, and a WooCommerce plugin that connects a partner shop in minutes.
  • Loyalty, birthdays and referrals. Spend measured in two overlapping windows with the kinder result winning, refunds subtracted, and every reward issued as an ordinary WooCommerce coupon locked to one email address.
  • A three dimensional hero. One compressed model wearing a label texture that WordPress extracts from each product, so changing the model in the media library changes the hero.

Results

  • Fifteen pages indexed by Google within twenty hours of launch. No backlinks, no promotion, no submission beyond a sitemap.
  • PageSpeed Insights, 21 September 2026: 100 for performance, accessibility, best practices and SEO on desktop; 93 to 96 for performance on mobile (simulated Moto G Power on slow 4G, two runs), with zero layout shift, on a home page carrying a lit, rotating three dimensional can. Lab scores; rerun them yourself on the live site.
  • Agent-readiness score 93, level 5 of 5, on an independent audit the same day: content, bot access control and MCP discovery all at 100.
  • A Google Shopping feed of one hundred and fourteen items, generated from live data with every attribute Merchant Center requires, so a price change on the site is a price change in the feed.
  • Five readers of one catalogue: the storefront, the shopping feed, the reseller API, a machine readable catalogue for AI assistants, and search.

The engineering behind those numbers

Every query is a persisted document. The storefront asks WordPress for a query by name rather than sending one. The shape of the data is fixed, cacheable on both sides, and an arbitrary request is refused. Caching is per fact, not per page. A cached response is tagged with the taxonomy terms it contains, so adding one product clears the responses that mention that collection and leaves the rest of the catalogue alone. Invalidation reaches the edge. When something is saved in WordPress, one batched message describes the change, the storefront turns it into the exact list of addresses affected, rebuilds them, and purges only those from the content delivery network. A stock change touches six or eight addresses. Nothing else moves. The WordPress origin is not reachable. It answers the application and the developer and returns a plain not found to everybody else. Media is served through the storefront, and every link and image in every transactional email was audited by rendering the email and searching the output rather than by reading templates.

What this means for a client project

A build of this shape is not a website with a shop attached. It is a catalogue with several readers, one of which happens to be a browser, and that difference is what makes the second surface cheap: a marketplace feed, a wholesale price book, a point of sale, a second brand or a second country becomes a new reader of existing data rather than a new project. It is the right choice when the brand is a reason people buy, when the catalogue will outlive the current design, when the site needs to feed something other than a browser, or when speed is a competitive position rather than a line in a report. It is the wrong choice for a five page brochure site, and we will say so. Scope drives the number more than anything else. A storefront with a catalogue, cart, checkout, accounts and the caching architecture underneath is already a serious build. Adding what PEWES carries on top, subscriptions, a reseller programme with tiered pricing, a partner API and a three dimensional product experience, multiplies it. We would rather have that conversation openly at the start than discover it in month three.

Deeper dives on pewesenergy.com

We wrote up the individual decisions on the shop’s own blog, from the shop’s point of view:

Stack

WordPress and WooCommerce, WPGraphQL with persisted queries and Smart Cache, Next.js App Router, Stripe, Rank Math, Cloudflare. Server side rendering with per fact caching, on demand revalidation from WordPress, and selective edge purging. The storefront is live at pewesenergy.com, and its own blog documents the engineering in detail. If you are deciding between this and a hosted platform, read our comparison with Shopify; if you want the same architecture for your shop, start on the headless WooCommerce page.