Rollout Context
Ecommerce web development: when headless Shopify is worth it
Lubie was founded by a mechanical engineer and an electrician who met working on heavy equipment in the Pilbara. Its SPL bags are purpose-built for single-point lubricator maintenance, with dedicated storage for cartridges, tools, new and used batteries, e-waste and hydrocarbon-contaminated materials.
That is not a product that sells itself from a thumbnail and a price. It is a product that has to be explained before anyone understands why it costs what it costs.
Why not just use a Shopify theme?
We should be straight about this: for most stores, a good Shopify theme is the right answer. If you sell t-shirts, candles or coffee, the product is self-explanatory, the customer knows what they are looking at, and the job of the site is to show it clearly and get out of the way. Paying for a custom build there is usually waste.
Lubie is the other case. The buyer is a maintenance technician or a procurement officer who needs to understand a compartment system before they can justify the purchase: how cartridges are organised, why used batteries are separated from new ones, how hydrocarbon-contaminated waste stays isolated, how much each size carries.
Standard themes are built around browsing, not explaining. You end up fighting the template — bending description fields and metafields into carrying technical content they were never designed for, and accepting a product page shaped like a fashion store’s.
So we went headless: Shopify keeps doing what it is genuinely best at, and the front end becomes a custom build.
What “headless” actually means here
The split is clean.
Shopify remains the commerce backend. Products, variants, pricing, inventory, orders and — critically — checkout all live in Shopify. The Lubie team manages the catalogue in Shopify Admin exactly as they would on any store. No developer is needed to change a price or add a product.
A custom Next.js application is the entire storefront. It requests product data from Shopify’s Storefront API and renders it through templates we control completely: the homepage, collection pages, product pages, policies and contact.
Checkout stays with Shopify. The cart is ours; the moment money is involved, the customer is handed to Shopify’s hosted checkout. This is deliberate and we would argue it in any project. Payment handling is a solved problem with serious regulatory and security consequences, and rebuilding it to save a redirect is a bad trade. Shopify maintains PCI compliance, fraud analysis and payment method support far better than a bespoke flow could.
The result: full design control where it creates value, and none of the liability where it doesn’t.
The part headless builds usually get wrong
A theme runs inside Shopify’s platform, which handles a great deal of security invisibly. The moment you build a custom front end with its own API routes, that protection is yours to provide — and this is where headless projects tend to be weakest, because the failure is invisible until it isn’t.
Three public endpoints exist here — cart operations, the contact form, and catalogue revalidation — and each is treated as hostile input.
Everything is validated and sanitised. Incoming payloads are checked against strict Zod schemas, and any HTML that could reach a page is sanitised. Nothing is trusted because it arrived from our own front end.
Every public route is rate limited, backed by Upstash where configured with an in-memory fallback otherwise. Without this, a contact endpoint is a spam relay and a cart endpoint is a free denial-of-service target.
Shopify webhooks are cryptographically verified. When Shopify notifies the site that a product changed, the request’s HMAC signature is checked with a timing-safe comparison before anything acts on it, with replay protection on top. An unverified revalidation webhook is an open invitation to have your cache poisoned by anyone who guesses the URL.
Security headers are generated at build time and applied across the site, and Sentry captures runtime errors so problems surface from monitoring rather than from a customer email.
None of this is visible on the storefront. All of it is the difference between a headless build that is genuinely production-grade and one that merely looks finished.
Analytics that wait for permission
The site runs GA4, Google Tag Manager and the LinkedIn Insight Tag — and none of them load until the visitor allows it.
The cookie preferences panel separates necessary storage (cart, session, consent itself) from analytics and marketing, defaults the optional categories to off, and remembers the choice. Tags are only injected after consent is given.
This is increasingly what privacy law expects rather than a nice gesture, and doing it properly at build time is far cheaper than retrofitting it later. It also means the analytics you do collect represent people who agreed to be measured — a smaller number, honestly reported.
Who this architecture is actually for
Headless ecommerce is genuinely better for a specific set of businesses:
- Technical or B2B products that need explanation, specifications, or compliance context a theme cannot accommodate.
- Brands with a strong identity where looking like every other Shopify store is a real commercial cost.
- Stores needing custom functionality — configurators, quoting, calculators, portals — that fights the theme model.
- Businesses with performance requirements that a theme plus a stack of apps cannot meet.
It is the wrong choice if the catalogue is simple, the product is self-explanatory, and the budget is better spent on photography and ads. We will tell you that before quoting, because a custom build that didn’t need to exist is the most expensive thing we could sell you.
The result: an industrial ecommerce storefront with the design freedom to explain a technical product, Shopify’s checkout and admin retained, every public endpoint validated and rate limited, webhooks cryptographically verified, and analytics that fire only with consent.
Visit Lubie, or read more about our Ecommerce Websites Perth service. The product photography used across the store is covered in our Lubie product photography case study.
