Headless commerce projects slip more often than monolithic ones, and they slip in different places. A digital-first apparel brand, around $40M in annual revenue, came to Bemeir wanting a replatform from Shopify Plus on a standard Online Store theme to a headless storefront on Hydrogen, with a 22-week target schedule from kickoff to launch. They had been told by their previous prospective agency that the schedule was unrealistic. The build shipped at week 23. This anonymized case study walks through where headless projects typically lose schedule, and the prevention patterns that kept this one inside its window.
The Brand’s Starting Position
The brand was running on Shopify Plus with a theme they had outgrown: roughly 18 months of accumulated theme customization, slow cart and checkout performance on mobile, and a content team frustrated by the constraints of theme-bound merchandising. They had a strong product team and a small in-house engineering function (two senior frontend engineers, one platform engineer) but had never run a headless build before. Their reasons for going headless were specific and good: a custom merchandising experience tied to user behavior, a content layer that did not have to fit theme conventions, and a performance budget that the existing theme could not hold.
The decision to stay on Shopify (rather than replatform the commerce engine) was deliberate. Shopify is the part of the stack that was working. The frontend was the part that was not.
Where Headless Projects Typically Slip
Across Bemeir’s headless engagements and the broader pattern visible in Forrester and Digital Commerce 360 industry data, headless projects lose schedule in five recurring places.
Loose contracts between frontend and backend. Without a clear, versioned API contract between the storefront framework and the commerce engine (and any other backend services), frontend and backend work cannot proceed in parallel cleanly. The frontend builds against assumptions, the backend changes shape, and the integration sprint becomes a debug sprint.
The image and asset pipeline. Headless storefronts have to make explicit decisions about asset CDN, image transformation, responsive sizing, and lazy-loading strategy. These decisions are usually deferred. They almost always come back as performance issues two weeks before launch.
Preview environments. Content teams need to see what they are publishing before it goes live. In a theme-bound site, preview is built in. In a headless site, preview is something the team has to build. If the build is bolted on at the end, content velocity collapses at launch.
SSR vs. ISR vs. CSR strategy decisions. Whether a given page is server-rendered, incrementally regenerated, or client-rendered has substantial implications for performance, cost, and editorial workflow. Teams often default to one strategy across the whole site and discover at performance testing that the defaults do not work for their specific traffic patterns.
Performance budget enforcement. Headless projects that do not enforce performance budgets at every PR end up doing a “performance sprint” near launch that, in practice, is a partial rebuild.
The Prevention Patterns That Held the Schedule
Each of the five typical slippage causes had a specific prevention pattern built into the engagement from sprint zero. The discipline of putting these in place before the first feature sprint was what created the parallelism the schedule depended on.
API Contract Defined in Sprint Zero
Before any feature work, the team defined a formal API contract between the Hydrogen storefront and the Shopify Storefront API plus the brand’s chosen headless CMS (Sanity in this case). The contract specified: query shapes the storefront would issue, response shapes it expected, error handling, caching behavior at each layer, and versioning strategy. The Shopify dev documentation and the Sanity GROQ reference were the authoritative sources.
This contract became a living document, owned jointly by the brand’s lead frontend engineer and Bemeir’s solutions architect. When something needed to change, the contract was updated first. The frontend team could build against the contract while the backend integration work was still being implemented, and the two streams reconverged cleanly because the contract was the source of truth.
Image Pipeline Decided in Week Two
The image and asset pipeline was treated as a first-week deliverable, not a late-stage detail. The decisions: Shopify’s image transformation API for product imagery (with the brand’s CDN in front), a defined responsive image strategy (srcset breakpoints, format negotiation for AVIF and WebP with JPEG fallback), and a lazy-loading approach with explicit dimensions to prevent layout shift. Content imagery from Sanity used Sanity’s image pipeline with similar discipline.
The reason this matters for schedule is that image strategy decisions cascade into component design. The product card component needs to know its image strategy on day one, not week eighteen. Component teams that have to redo their image handling near launch often have to redo their entire component to handle layout-shift, accessibility, and performance correctly.
Preview Environments Built in Sprint One
Preview was a sprint-one feature, not a launch-week feature. The Hydrogen build had a preview mode wired up against the Sanity dataset, with a clear authoring workflow: editors saw their content in the actual storefront before publish, with deep links from Sanity into the preview render of the affected page. The preview environment ran on its own URL with cache headers tuned for low-latency content updates.
This is a place where investing two weeks early prevented at least four to six weeks of pain at launch. Content teams who cannot see what they are publishing slow down the feature work that depends on content being ready, and the slowdown shows up in the schedule one to two months later.
SSR/ISR Strategy Decided Per Page Type
Rather than defaulting to one rendering strategy, the team mapped page types to strategies based on traffic patterns and freshness requirements. Product detail pages used incremental regeneration with a short revalidation window (because product data changes occasionally and traffic is high). Category pages used server-side rendering with strong caching at the edge (because filter combinations are unbounded). Cart and account pages used client-side rendering (because they are personalized and behind authentication). The home page used a hybrid: static shell with client-side personalized blocks.
This per-page-type decision was made in week three and validated against representative traffic patterns from the existing Shopify Plus site’s analytics. The result was that performance testing in week 18 confirmed the strategy held up, rather than discovering that defaults did not.
Performance Budgets Enforced at Every PR
A performance budget was set early: largest contentful paint under 2.0 seconds at the 75th percentile on mobile, cumulative layout shift under 0.05, total blocking time under 200ms, JavaScript bundle size under defined thresholds per route. The CI/CD pipeline ran Lighthouse against representative pages on every pull request, and PRs that regressed budgets blocked merge until the regression was justified or fixed.
This is a discipline the Web Almanac consistently shows separates top-decile commerce performance from average. It also prevents the launch-week scramble that headless projects without budget enforcement almost always experience.
Sprint Structure for Parallel Frontend and Backend Work
The 22-week schedule depended on frontend and backend work running in parallel from sprint two onward. The structure that enabled this:
Two-week sprints, eleven sprints total plus a hardening sprint. Each sprint had a frontend lead and a backend lead, joint sprint planning at start, joint sprint demo at end, daily standups with both streams in the room. Cross-stream dependencies were tracked explicitly, and any dependency that was not unblocked within 48 hours escalated to the solutions architect.
Frontend and backend teams worked off the same API contract document. When the contract changed, both teams attended the change review. This lightweight ceremony, maybe 30 minutes a sprint, prevented the drift that breaks parallel development.
Sprint zero was three weeks (architecture, API contract, environments, image pipeline, preview infrastructure, performance budget definition, CI/CD with Lighthouse gates). Every sprint after that ran two weeks. Sprint twelve was a hardening sprint focused on performance, accessibility (WCAG via NIST guidance), security review, and load testing.
Common Headless Slippage Cause and Prevention Pattern
The summary table below captures the patterns this engagement followed, against the recurring slippage causes that headless projects across the industry tend to share.
| Common Headless Slippage Cause | Prevention Pattern Used |
|---|---|
| Frontend and backend diverge on API expectations | Versioned API contract document, owned jointly, updated before code changes |
| Image pipeline becomes a launch-week problem | Pipeline decisions (CDN, transformation, srcset, lazy-load) made in week two |
| Content team blocked by missing preview | Preview environment built in sprint one as feature-one |
| One rendering strategy applied across all pages | Per-page-type SSR/ISR/CSR decision in week three, validated against real traffic |
| Performance regressions accumulate silently | Lighthouse budget enforcement on every PR, merge-blocking |
| Cross-stream dependencies block sprints | Daily standups with both streams, 48-hour dependency escalation rule |
| Late discovery of CMS authoring gaps | Editor walkthroughs every two sprints, not at UAT |
| Cart/checkout performance issues at launch | Real-device perf testing in sprint eight, not week 21 |
| Search and filtering performance under load | Load testing in hardening sprint with realistic traffic and filter combinations |
| Hosting and CDN configuration finalized too late | Infrastructure-as-code from sprint zero on AWS, identical staging and prod |
What the Brand Got
The build shipped at week 23, one week past the 22-week target, which is well inside acceptable variance for a headless replatform. Lighthouse mobile scores moved from the high 40s on the legacy theme to consistent 90+ on the new storefront. Cart abandonment dropped meaningfully in the first 60 days. Content velocity, measured by published content updates per week from the editorial team, more than doubled because the preview environment removed the publish-and-pray loop.
Bemeir continued in a retainer capacity post-launch, with the same engineering team, handling iteration on merchandising experiments, performance work as new features were added, and the inevitable Shopify and Hydrogen platform updates. Brands weighing a similar build alongside a possible move to a more flexible commerce engine can also look at how the Shopware practice approaches the same headless seams from a different platform angle. The transition from project to retainer was deliberately structured at week 22, not improvised after launch.
Why the Schedule Held
The discipline that kept this project on schedule was not heroic engineering. It was unfashionable rigor in the first three weeks. API contract before features. Image pipeline before components. Preview before content. Rendering strategy before performance testing. Performance budgets before regressions. None of these is glamorous, and none of them ships visible product, but each one prevents a category of slippage that headless projects routinely fall into. The reason a 22-wee
