LIVE LABS / DEVLOG 001 / 28.10.2026
A technical workshop report from the development of LEAFerservice.
Why I'm not simply replacing my Shopify store with a headless one
I've been working on technically rebuilding LEAFerservice for a while now. The goal is a custom-developed storefront that gives me significantly more freedom with product worlds, manufacturer landing pages, and configurators than a classic theme. At the same time, there is one requirement that takes precedence over any architectural decision: the existing store must be able to continue selling.
That is exactly why I decided against a big-bang relaunch. I'm keeping the current Shopify Liquid store live and developing the new headless interface in parallel. If I'm working on a React Router build or a preview throws an error, that must not mean that customers suddenly can no longer place orders.
With this post, I'm launching Live Labs: a development diary in which I want to document approximately every two days what I have implemented, where I'm technically stuck, and what decisions I make. Not a retrospectively smoothed-over success story, but a transparent look into the ongoing development.
The vision: from product catalog to configurable solutions
I don't want to simply build another store frontend. The real idea is to more closely connect products, advice, and interactive tools. Anyone looking for a substrate should not only see a list of items, but also understand suitable mixtures and eventually be able to configure them themselves. With plant lighting, I want to move more towards understandable room and light planning in the long term. Manufacturer landing pages should present the products with real technical data, suitable add-ons, and clear purchasing paths.
This requires a consistent design system. Compact typography, high-quality images, mobile-friendly elements, and a clean layout should run through the entire store. I don't want individual areas to seem like separate experiments – even if Liquid and headless are temporarily running side by side in the background.
My architectural decision: one backend, two storefronts
Shopify remains my authoritative commerce layer. That's where products, variants, prices, and the data that are crucial for sales are located. The checkout also remains with Shopify. I have no reason to build a second product catalog for the new interface and thereby create new synchronization problems.
SHOPIFY ADMIN
Product data · Variants · Prices · Checkout
↓ a shared commerce database ↓
|
LIQUID Current live store Productive sales |
HEADLESS Hydrogen / React Router Vercel preview and tests |
↓ Shopify Checkout ↓
Order and Fulfillment
I am developing the headless side based on Hydrogen or React Router. For builds and previews, I use a Vercel-based pipeline. The structure remains modular: the storefront is interchangeable, the existing product IDs and the checkout are not.
Technical background: What does "headless" actually mean here?
The presentation layer is decoupled from the commerce backend. Shopify continues to handle the commerce functions; a standalone application renders pages and interactions. This offers flexibility, but also increases responsibility for routing, caching, error handling, SEO, and deployment.
A concrete learning: "Active" is not the same as "purchasable"
Today was a good example of why I prefer to check technical assumptions against the actual store data. In the Shopify admin, 150 products were set to active. In total, that was 356 variants. During the review of the inventory policies, ten Romberg variants had to be corrected. After that, inventory tracking was disabled and ordering allowed for all 356 checked variants.
But the work was not done. A second check initially showed only 122 of the 150 active products as published – both in the online store channel and the headless channel. I subsequently added another Blumat product to both channels. For the remaining publications and complete checkout tests, there was still no completed confirmation at this point.
My most important learning from this: product status, inventory policy, channel publication, and actual purchasability are four different things. A green "Active" in the admin does not replace a test of the product page, variant, cart, and checkout.
Why do I check the sales channels separately?
An active Shopify product can be unpublished for a specific sales channel. This also applies even if its variants can generally still be sold. I therefore have to specifically match the publication for Liquid and headless.
Original data instead of nice demo content
With the manufacturer pages, it is important to me that the interface does not rely on placeholders. I want to use original images, real variants, verifiable prices, technical features, and correct delivery information. This also includes the respective dealer terms and clarification on which image and text material I am actually allowed to use.
This is not just an editorial question. Data quality influences variant selection, search engine snippets, internal linking, and ultimately conversion. Even the highest quality landing page is useless if the right product is not orderable in the end.
What is still open with the deployment pipeline
The headless preview has already shown parts of the purchasing process. At the same time, there were failed builds and a runtime error. A deployment can be considered ready at the platform level and still fail on an important route. That is why I will consistently separate CI successful, Build successful, Route reachable, Product data correct, and Checkout actually usable in the future.
I will not switch the live store to a new architecture as long as this chain does not work reliably. As of this post, the headless storefront is not yet confirmed as production-ready.
Why is a successful Vercel build not enough?
A build initially confirms that the project could be built. Errors can only occur during a server request, when loading product data, or during the checkout transition. That is why I also need runtime and end-to-end tests.
SEO belongs in the architecture for me
Switching from Shopify Liquid to headless commerce is not just about components and API calls. I want to preserve existing product handles, relevant URLs, and established search engine signals as much as possible. This includes canonical tags, structured product data, server-side accessible content, internal linking, and, if necessary, clean 301 redirects.
Especially with specialized topics like a substrate configurator, plant lighting, and manufacturer landing pages, organic findability is an important part of the concept. That is why I do not check the SEO effects until the day of the relaunch.
My plan for the controlled switch
- Secure Liquid: Existing product pages and purchasing processes remain available.
- Complete product data: Check approved active items, variants, images, and sales channels.
- Unify design: Build manufacturer landing pages and product worlds according to the same quality standards.
- Stabilize headless: Fix build and runtime errors, make the preview reliable.
- End-to-end test: Test mobile display, cart, checkout, SEO, and redirects.
- Switch in a controlled manner: Only switch the production storefront after a successful check – with a fallback option.
What happens to the Liquid store during the migration?
It remains the productive sales channel and will continue to be maintained. New approved products do not have to wait for the headless relaunch. A switch will only take place after completed technical acceptance.
What I will document next
In the next Live Labs entry, I want to go deeper into product publication: How do Shopify product status, Inventory Policy, and Sales Channels relate to each other? How do I check if a product is really purchasable? And how do I ensure that Liquid and headless show the same variants?
After that, it will be about the headless pipeline, manufacturer landing pages, and the question of how a sophisticated store frontend can be further developed without endangering ongoing operations.
My standard remains simple: New technology is only progress when it makes the store better for customers – and sales continue to work during the process.
Live Labs appears approximately every two days, if possible. The posts document the respective development status; open points remain explicitly marked as open.