Short answer: most of the cost and most of the regret in a headless WooCommerce project come from decisions that were never made explicitly. Before anyone estimates the build, the twelve questions below should have answers. They take an afternoon with the right people in the room and they change the number by a multiple. We ask every one of them on our first call. If you are still deciding whether headless suits your shop at all, start with our headless WooCommerce guide.
1. What stays in WooCommerce and what moves to the front end
Products, orders, stock, customers and payments belong in WooCommerce. Rendering belongs in the front end. The grey zone is everything in between: cart logic, price rules, tax, shipping calculation. Our default is to keep every business rule in WooCommerce and have the storefront call it, so a rule changed in the admin applies everywhere. The alternative, re-implementing rules in the front end, is faster to demo and slower to live with.
2. Which plugins you rely on today, and what each one does
Make the list. For each plugin write one line: does it manage data, or does it produce something on the page? Data plugins keep working. Page plugins, sliders, badges, popups, wishlist widgets, product filters that render HTML, will be rebuilt in the front end. This list is the first real estimate of scope.
3. Checkout: WooCommerce’s or your own
A headless build can hand the visitor to WooCommerce’s checkout page for the last step, or build the whole checkout in the storefront with the payment provider’s elements embedded. The first is cheaper and keeps every payment plugin working. The second is the reason many shops go headless at all: one page, no reload, designed like the rest of the site. Decide this early because it changes the payment integration, the email flow and the testing plan.
4. Accounts: how much of My Account you need
Orders and addresses are the minimum. Invoices, returns, subscriptions, wishlists, reviews, saved payment methods and password reset each add a screen and an API contract. List what customers actually use today from your analytics, not what the theme offered.
5. Search and filtering
Filtering by three attributes across two thousand products is a different problem from filtering ten products by colour. Decide which attributes filter, whether counts must update live, and whether search needs typo tolerance. Small catalogues can be filtered in the API; large ones need an index, and that is a separate component with its own sync.
6. How fresh “fresh” has to be
Stock changing once a day and stock changing every minute lead to different caching designs. On our builds, saving anything in WordPress rebuilds only the pages that show it, within seconds; a stock change touches the product page, its category and a few lists. If you need live stock at the moment of add-to-cart, that is a real-time call layered on top of the cached page, and it should be in the plan.
7. Media: who serves the images
WordPress stores them. The storefront should serve them, resized and converted, from its own domain, so the CMS address never appears in the page and the image pipeline is one system. Decide now whether the existing media library is clean enough to migrate or needs a pass first.
8. Emails
WooCommerce sends transactional emails with links to the WordPress domain. Every one of those links has to point at the storefront instead, and the templates usually need redesigning to match. It is an easy thing to forget and an embarrassing thing to discover from a customer.
9. Preview and staging for editors
Editors will ask to see a product page before it is published. In a headless setup that is a feature: the storefront fetches the draft with the editor’s credentials and renders it on demand. Decide whether you need it at launch or later; it is easier to plan than to bolt on.
10. Who else will read the catalogue
A Google Shopping feed, a marketplace, a wholesale partner, an app, an AI assistant. If any of these are on the roadmap, the API should be designed for several readers from the start. It costs little then and a lot later. On our demo shop the same catalogue has five readers, and each new one was days, not months.
11. Migration and redirects
If the shop already ranks, every existing URL either keeps its address or redirects to the new one, and the list is written before launch, not after. Product and category URLs are usually kept; blog and filter URLs are where the surprises live.
12. Who maintains it afterwards
Two applications, two deployments, two sets of updates. Decide whether that is your team, ours, or both, and put it in the contract. A headless shop with nobody responsible for the front end after launch is the most common failure we are asked to rescue.
The one-page version
| Decision | Cheaper option | The option people actually want |
|---|---|---|
| Checkout | WooCommerce checkout page | Custom checkout in the storefront |
| Accounts | Orders and addresses | Invoices, subscriptions, returns, wishlist |
| Search | API filtering | Dedicated search index |
| Freshness | Rebuild on publish | Rebuild on publish plus live stock check |
| Preview | After launch | At launch |
| Readers | The website | Website, feeds, partners, apps |
Bring the answers, or bring the questions and we will work through them together. Either way the estimate you get afterwards will be one you can trust. The build itself is described on our headless WooCommerce page, and if you are still weighing headless against a hosted platform, start with our comparison with Shopify.
Frequently asked questions
Which checkout you use, how much of My Account you need, how search works, how fresh prices and stock must be, who serves images, how editors preview content, who else reads the catalogue, how URLs are migrated and who maintains the front end.
Yes. Sending customers to the WooCommerce checkout page is the cheaper option and keeps your payment plugins working. A custom checkout in the storefront looks better but costs more to build and test.
Not always. Small catalogues can filter through the API. Larger catalogues, or shops that need typo tolerance and fast facets, usually need a dedicated search index.
Someone has to own both applications: WordPress and WooCommerce updates, and the front end deployments. Agree in the contract whether that is your team, the agency, or both.
