CASE STUDY · HEADLESS COMMERCE & E-COMMERCE PERSONALIZATION
A headless commerce rebuild for a growing D2C brand.
- 4.2→1.8 secondsPage load time down from 4.2 to 1.8 seconds
- 7%Conversion up 7%
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised D2C brand. Name withheld under confidentiality.
A headless storefront connected through APIs. The existing commerce platform stayed as the backend for catalogue, orders and payments. The new frontend handled everything customers saw, from home page to checkout steps.
- 1The brand's store ran on rigid templates.
- 2Every design change meant fighting the theme.
- 3A growing stack of apps added scripts to each page, and pages loaded slowly, especially on mobile.
- 4Marketing wanted campaign landing pages and richer product pages.
- 5Engineering could not ship them without risking the checkout.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01After the first slice went live, product pages looked fast but some showed out-of-date stock
The cache served stale inventory, so a few customers added items that had already sold out. We split the data. Product descriptions and images stayed cached.
- PROBLEM 02Stock and price were fetched fresh, with a short cache and an explicit refresh when the inventory system sent an update
We added a final stock check at cart and checkout. The speed gain held, and the stock errors stopped.
- PROBLEM 03A second problem came from redirects
A few hundred old product URLs from past campaigns were not in the first redirect map and returned errors for a day. Search Console reports showed it. We pulled the full list of URLs from server logs and the sitemap history, added the missing redirects and made the log review a standing step in every later release.
- PROBLEM 04We pulled the full list of urls from server logs and the sitemap history, added the missing redirects and made the log review a standing step in every later release
03 · THE PROCESS
How we ran it.
We worked in phases with a fortnightly demo and a shared board.
- 01Step 1
Audit: we measured speed by template, listed every app and script on the pages, and ranked templates by traffic and revenue.
- 02Step 2
Foundation: we set up the frontend project, the design system, the API layer and the deployment pipeline.
- 03Step 3
Slices: we built product pages first, then collections and search, then cart and checkout. Each slice went live to a small share of visitors before the next began.
- 04Step 4
Migration: we widened traffic in steps and kept the old storefront available for fast rollback.
Daily check-ins with the client's marketing lead kept design decisions quick.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
Marketing builds campaign pages from reusable components without waiting on a developer.
- NOW 02
Every release is checked against speed budgets, so slow pages are caught before launch.
- NOW 03
New apps and scripts need a speed review before they go on the site.
- NOW 04
The team runs experiments on product pages as a normal part of the week.
- 4.2→1.8 seconds
Page load time down from 4.2 to 1.8 seconds
- 7%
Conversion up 7%
05 · WHAT WE BUILT
How it works.
- Next.js frontend with server rendering for product and collection pages, and static generation where content changed rarely.
- A thin API layer between the frontend and the commerce backend.It cached catalogue reads and shielded the frontend from backend changes.
- Images served through an optimising pipeline with sized variants and lazy loading.
- Third-party scripts audited one by one.Several were removed, the rest loaded after the page was interactive.
- Cart and checkout used the platform's own checkout for payment, to keep payment handling and compliance simple.
- Redirect maps, canonical tags, sitemaps and structured data were carried over and checked page by page.
- Controls
- Each release went through automated checks for speed, accessibility and broken links before it reached customers. A feature flag let us switch any new template back to the old storefront in minutes. Error monitoring watched the cart and checkout steps closely, with alerts to both our engineers and the client's on-call person.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- The brand's store ran on rigid templates. Every design change meant fighting the theme. A growing stack of apps added scripts to each page, and pages loaded slowly, especially on mobile. Marketing wanted campaign landing pages and richer product pages. Engineering could not ship them without risking the checkout. The team felt the platform, not the brand, set the pace.
- What did Brandsmashers build?
- A headless storefront connected through APIs. The existing commerce platform stayed as the backend for catalogue, orders and payments. The new frontend handled everything customers saw, from home page to checkout steps.
- How was the work run?
- We worked in phases with a fortnightly demo and a shared board.
- What were the results?
- Page load time down from 4.2 to 1.8 seconds; conversion up 7%.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
