Composable commerce
Headless commerce
Headless is sold as the modern default. It is not — it is a trade. You gain flexibility and speed, and you pay for them in editorial experience and moving parts. Whether that trade is worth it comes down to one question asked far too late: how many places does this content need to appear?
What we build
Decoupled storefronts on Shopify
The Storefront API serves product and cart data to a front end you control, while checkout stays on Shopify so you are not rebuilding the part that handles money. That hybrid is usually the sensible shape — custom where it differentiates, platform where it does not. Available on Plus and standard alike.
Decoupled front ends on Adobe Commerce
GraphQL and REST against Adobe Commerce, which suits a decoupled front end particularly where the commerce logic behind it is genuinely complex — multi-currency, duty and tax rules, inventory across locations.
Built in Next.js, in production
Next.js is a substantial part of what we build outside commerce, so this is a recommendation made from running it rather than from a preference — see our Next.js work. The framework matters less than the decision to decouple at all, which is the expensive part.
The content layer, properly modelled
A headless build is only as good as its content model, and that is where most of them go wrong — fields designed around one page template, then bent when the second destination arrives. We model content around what it is, not where it first appears, the same discipline behind our structured publishing work.
Preview that editors will actually use
The most common regret in headless projects, and the least discussed at the point of sale. In a themed store an editor sees the page; in a headless one they see fields. If preview is not deliberately built, the people publishing every day end up worse off so the developers can be better off. We budget for it explicitly rather than treating it as a stretch goal.
Performance you can measure
Pre-rendering removes a class of performance work rather than optimising it, which matters when traffic is spiky or page speed maps to revenue. We measure rather than assert: the audits we run against our own site walk every route and fail the build on a regression, and we hold client work to the same bar.
When we would tell you not to
Three situations where headless costs more than it returns, and a themed storefront is the better engineering decision.
One website is the only consumer
The original argument for headless is content reaching more than one destination. If there is no app, no partner system and no second brand — and none of them are funded — you are paying an architecture cost for an option you may never exercise.
A small team with no developer on call
Headless assumes someone technical is available when the front end needs to change. Without that, every layout tweak becomes a ticket where it used to be a page edit, and the team that publishes daily pays for the flexibility the team that deploys quarterly enjoys.
The site is slow for reasons headless will inherit
Unoptimised images, a dozen overlapping apps, a theme carrying years of edits. A new architecture inherits every one of those. Fixing them on the current stack is cheaper and usually recovers most of the speed people are chasing.
The middle option people forget
The choice is not binary. A traditional platform can serve content through an API to a second destination while continuing to render its own storefront — which covers a lot of the "we might need an app one day" cases without paying the full architectural cost up front.
It is worth ruling out before committing to a rebuild, because it is dramatically cheaper and reversible. Reversibility is worth a great deal on a decision this expensive.
The proof
Work we have shipped, not a capability deck.
- SES (formerly Intelsat)Not commerce — Laravel APIs behind Next.js front ends across three platforms, which is the decoupled architecture a headless storefront uses.Read the case study
- Western Sydney UniversityA Next.js front end against a separate content and data layer, in production at scale.Read the case study
- LOOPShopify, themed rather than headless — included because the plugin work behind it is the same API-first integration a decoupled storefront depends on.Read the case study
Commerce work we do
Magento & Adobe Commerce
Builds, replatforms, upgrades and performance rescue — including SAP integration.
Magento upgrades
Version upgrades and extension audits — and when the platform is not what needs the money.
Shopify & Shopify Plus
Storefronts, theme builds, app integration and headless front ends.
Shopify Plus
Checkout extensibility, B2B and D2C together, multi-storefront — and when the tier is not worth it.
E-commerce development
The whole practice: platform selection, build, integrate and run.
Migration & replatforming
Moving between platforms without losing data, rankings or trading days.
Magento to Shopify
The specific route, and an honest view of when not to take it.
WooCommerce
WordPress commerce where the catalogue and the content live together.
E-commerce & retail
The sector view — what retail platforms are actually asked to do, and where they break.
B2B & wholesale commerce
Company accounts, contract pricing, quotes, credit terms and ERP-held price logic for trade suppliers.
Adelaide commerce
Adobe Commerce for South Australian retailers — including the duty free store trading at Adelaide Airport.
New Zealand commerce
GST, rural freight and trans-Tasman selling — and the duty free stores running across airports in both countries.
More on commerce
Two Thirds of Australian Retail's Page Weight Isn't Theirs
We measured 21 of Australia's largest online retailers. None scored above 44. The median site ships 7MB, and 62% of it is third-party code the retailer didn't write.
What Does a Shopify Plus Build Cost in Australia?
What Shopify Plus actually costs Australian retailers — the platform fee, the transaction economics nobody models, and what drives a build quote up or down.
ERP Integration for E-commerce: What It Actually Costs
Why ERP integration is the line item that blows e-commerce budgets, the four questions that decide the price, and how to tell real-time requirements from imagined ones.
Adobe Commerce vs Shopify Plus for Australian Retailers
Where Adobe Commerce genuinely beats Shopify Plus, where it does not, and the three questions that actually decide it — from a team that builds on both.
Adobe Has Patched StyleSmuggler. Patching Is Not the Whole Job.
Adobe has released APSB26-146 for CVE-2026-75650. Apply it now — but a patch does not clean a store that was already compromised. What to preserve before you patch, what to check after, and the disclosure clock most coverage skips.
Selling Into Australia and New Zealand From One Store
Whether to run one store or two across the Tasman, what actually differs between AU and NZ commerce — GST, freight, currency — and the duplication that costs more than it solves.
Ecommerce practice lead
Maxim Baibakov — Chief Technology Officer - Australia
Adobe Commerce and Shopify work here runs through a dedicated commerce team rather than being picked up by whoever is free.
Common questions
Do we need a headless storefront?
Probably not, and that is the honest answer for most single-storefront retailers. Headless earns its cost when the same content and product data must serve more than one destination — a site, an app, a partner system — or when the front end has to change independently of the commerce platform. If one website is the only consumer, the standard theme layer is usually the better engineering decision.
What does headless actually cost us?
Two things, and neither appears on an invoice. The editorial experience regresses: in a themed store an editor sees the page, in a headless one they see fields, and preview is something that has to be deliberately built and budgeted. And the moving parts multiply — a commerce backend, a front end and a build pipeline instead of one system to host and patch. Small teams feel both hardest.
Is headless faster?
It can be, and speed is rarely the reason it is worth it. A pre-rendered front end on a CDN removes a class of performance work rather than optimising it, which matters when traffic is spiky or page speed maps to revenue. But a well-built themed storefront is fast too, and most stores that feel slow are slow for reasons a new architecture will inherit — unoptimised images, too many apps, a bloated theme.
Can we go headless on Shopify?
Yes. The Storefront API serves product and cart data to a front end you control, and checkout can stay on Shopify so you are not rebuilding the part that handles money. That hybrid is usually the sensible shape: custom where it differentiates, platform where it does not.
What about Adobe Commerce?
Adobe Commerce exposes GraphQL and REST APIs and is well suited to a decoupled front end, particularly where the commerce logic behind it is genuinely complex. The question is the same one: is there a second destination for this content, or is the front end constrained in a way the platform will not let you fix?
What do you build the front end in?
Usually Next.js. It is a substantial part of what we build outside commerce as well, so the recommendation comes from running it in production rather than from a preference. The framework matters less than the decision to decouple at all — that is the expensive part, and the one worth arguing about first.
Can we start themed and go headless later?
Usually, and it is often the right sequence. A well-structured themed storefront with a clean content model is not a wasted step toward a decoupled front end — the product data, the integrations and the operational knowledge all carry over. Deferring the decision until you have a concrete second destination is cheaper than committing early on the possibility of one.
Trusted by
“We partnered with Shakewell in 2024 to help improve and maintain our website technology. The team are friendly, diligent and routinely demonstrate a breadth of technical understanding that is hard to find. Their support has put us in a much stronger position to scale and enhance our web presence.”
Aidan Arentz
Digital Product Owner of Merivale
“I’ve worked with Michael and the Team for a number of years now on a web development project of strategic value to the University. Michael and the team work in deep partnership and are genuinely invested in the success of the project and the maximising the impact it can deliver to end users. Always exceeding expectations, you will not find a more amiable, grounded and technically proficient team!”
Kelly Whitney
WSU Associate Director; Careers, Talent & Organisational Success
Engagement models
How we work
Four straightforward ways to engage us. Pick the one that fits, or mix them as your needs change.
Staff Augmentation
Add experienced Shakewell developers, designers or specialists directly to your own team. Engagements typically run three to twelve months, but can be as short or long as you need — you get the skills without the commitment and cost of hiring full-time.
About staff augmentationFixed-Scope Projects
Have a defined outcome in mind? We scope it, price it and deliver it as a project — a clear timeline, agreed milestones and a single point of accountability from kickoff to handover.
Embedded Delivery Teams
For larger or longer-running work, a cross-functional Shakewell team — development, design and delivery management — plugs in as your delivery arm, working to your priorities and your reporting cadence.
Support & Maintenance
Already live? We keep websites, stores and apps secure, updated and performing through ongoing retainers — business-hours support as standard, with 24/7 coverage available for critical issues.
About support & maintenance