What you are actually buying

People who ask for a headless storefront usually arrive with a number in their head that came from a theme build, and the number is wrong by a multiple. This is not a pricing page. It is an explanation of what the work is, so that the conversation can start somewhere useful.

The short version: a theme hands you a rendering layer that somebody else designed, and you spend your budget bending it. A headless build deletes that layer. Everything it used to do for free is now yours to design, and everything it used to do badly is now yours to do well.

What a theme gives you, and what it takes

A WooCommerce theme is not a design. It is a few hundred template files, a cart, a checkout, an account area, product filtering, pagination, search, breadcrumbs, a sitemap, structured data, order emails, and a thousand small behaviours you never think about until they are missing. That is an enormous amount of software, and you get it for the price of a licence.

What you pay for it is control. The markup is decided for you. The scripts are decided for you. When a plugin adds a stylesheet to every page on the site because one page needed it, that is decided for you too. You can fight each of those decisions individually, and most WordPress projects are exactly that fight, repeated until the budget runs out.

There is a point where the fight costs more than the rebuild. That point arrives sooner than people expect, and it arrives the moment the brand matters more than the calendar.

The list nobody itemises

When the theme goes, this is what has to exist again. Every item here was built for this site, and every item takes real time:

• The catalogue. Listing, filtering across several attribute taxonomies at once, sorting, pagination, price ranges, search, and the empty states for every combination that returns nothing.
• The cart. Not a page: a piece of shared state that has to stay correct while somebody clicks the plus button eight times in two seconds, survive a reload, survive signing in halfway through, and never show a number that the server disagrees with.
• Checkout. Addresses, validation per country, shipping selection, tax, payment, and the failure paths. The failure paths are most of the work.
• The account area. Orders, order detail, invoices, addresses, payment methods, password changes, email changes, and every screen a customer reaches only when something went wrong.
• Authentication. Sign in, register, sign out, social sign in, and password reset. Password reset alone is a flow with four screens and three ways to fail.
• Everything an SEO plugin used to print. Titles, descriptions, canonicals, Open Graph, structured data, the sitemap, the robots file. The plugin still decides the values. The storefront has to render them.
• Transactional email. WooCommerce still sends it, but every link and image inside it points at a server the customer is never supposed to see.
• The long tail. Redirects, 404 pages, pagination canonicals, feeds, the favicon set, the web manifest, offline behaviour.

None of that is exotic. All of it is invisible when it works. A quote that does not include it is a quote for the first demo, not for a shop.

Where the time actually goes

In rough thirds, and the thirds are not the ones people expect.

The first third is the data contract. WooCommerce holds products, variations, attributes, terms, prices, stock, orders and customers. Deciding exactly which shape of that data the storefront is allowed to ask for, and freezing it, is the single decision that determines whether the project stays fast. On this site every query the front end can make is stored inside WordPress as a persisted document with a name. The storefront asks for a name, not for a query. That means the data shape is fixed, cacheable on both sides, and impossible for a stray request to abuse.

The second third is caching, and it is the one that separates a fast site from a site that was fast on launch day. Anything can be fast when it is empty. Staying fast while an editor changes a price, a warehouse changes stock and an author publishes an article means knowing, for every piece of cached output, exactly which facts it contains. On this site a cached response is tagged with the facts inside it rather than with the page that served it, so adding a drink to one collection clears the responses that mention that collection and nothing else.

The last third is the interface. This is the part clients imagine is the whole job. It is the most visible third and usually the smallest.

Two levels of ambition

There is a baseline headless storefront, and there is whatever this site is. They are different projects.

The baseline is a catalogue, a cart, a checkout, an account area, the SEO surface and the caching architecture underneath it. Everything in the list above, done properly, with a design that is yours. That is already a serious build, and for most brands it is the correct one. It is the version where the storefront is a better shop.

The other version is the one where the storefront becomes the product. On this site that meant a subscription engine built rather than bought, because the behaviour we wanted did not exist in a plugin. It meant a reseller programme with tiered pricing, a booking system for sales calls, and an API that lets a partner place orders against the same catalogue. It meant a three dimensional product viewer, a machine readable catalogue for AI agents, and a product feed for Google Shopping generated from the same data as the shop.

Each of those is a feature with its own edge cases, its own admin screens and its own failure modes. They multiply the work, and they are the reason two headless projects can differ by a factor of four.

What you get that you cannot add later

Some things are only available if they are designed in at the start, and this is the part worth reading twice.

Speed as a property, not an optimisation. Pages are built ahead of time and served from cache; the parts that genuinely differ per visitor arrive separately. There is no plugin that can slow the front end down, because the front end does not run plugins. On this site that produces scores in the nineties on mobile and full marks on desktop, on a page that carries a real three dimensional model.

A front end with no ceiling. The hero on this site is a real can, lit and rotating, assembled from a model that an editor can replace in the media library. No theme would have allowed it. More to the point, no theme would have allowed it without costing the rest of the page its speed.

One catalogue, many surfaces. The same WooCommerce data becomes the shop, a Google Shopping feed of a hundred and fourteen items, a machine readable catalogue for AI agents, and a reseller API. Nothing is welded to a template, so a new surface is a new reader of existing data rather than a new project.

An origin nobody can reach. WordPress on this site answers the storefront and the developer and returns a plain 404 to everybody else. That is a decision that has to be made while the links are being designed, not afterwards.

The honest cost

Three things get worse, and pretending otherwise wastes everyone’s first meeting.

The block editor preview stops matching the live page, because the live page is rendered somewhere else. Editors write into fields and check the result on the site.

Anything a plugin used to print on the front end has to be rebuilt. A plugin that only stores data is free. A plugin that renders is a rewrite.

You run two deployments instead of one. That is a real operational cost, and it is the reason a small brochure site should not do this.

How to tell whether this is for you

It is worth it when the brand is a reason people buy, when the catalogue is going to 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 score in a report.

It is not worth it when the site is five pages and a contact form, when nobody on the team will own two deployments, or when the honest requirement is to launch in three weeks.

If you are reading this while deciding, the useful next step is not a quote. It is a list: what the shop must do on day one, what it must do in year two, and which of those a theme would have to be fought into doing. That list is the whole conversation.

This shop is a working demonstration of what a headless WooCommerce build is capable of, and everything described here is running on it. If you are weighing a build of your own, it was made by Pavels Web Solutions.