Headless shop: which customer task justifies the work?
A custom storefront needs a concrete purpose. An example separates brand presentation, specialised buying workflows and ongoing operation.
The decision to build a headless shop should depend on a concrete customer task. If a suitable theme already supports the buying journey, a custom frontend needs an additional benefit to justify it. A desired new brand presentation is initially a design brief.
What separation changes
Headless separates the visible storefront from the commerce system behind it. The custom frontend uses interfaces for capabilities such as products and the cart. One commerce platform can still provide those capabilities. Composing the whole system from specialised services is a further architectural decision.
Design freedom brings work on the custom frontend: deployment, dependencies and changes need attention. Shopify therefore identifies both limits in existing themes and apps and the necessary development and maintenance as decision factors.
A manageable catalogue as the starting point
A fictional office-supplies merchant plans a new shop. The initially known requirements cover a catalogue, product pages and purchasing; the brand presentation is to be refreshed. A room-based project list is an additional hypothetical requirement, not a confirmed need.
Case | Clarify first | Consequence for the decision |
|---|---|---|
New brand presentation | Try typography, images and navigation in a suitable theme | No demonstrated functional gap yet requiring a separate frontend |
Room-based project list | Collect items by room, save the list and buy later; examine existing extensions | Investigate a custom frontend further if a relevant gap is demonstrated |
Maintenance only occasionally available | Who handles changes and incidents in the custom frontend | Establish reliable support before implementation or postpone the project |
Headless is therefore not justified in the basic scenario. The assessment could change for the project list if standard functions and suitable extensions do not adequately support the described task. A prototype would then need to show which part the custom frontend handles better.
Operation extends beyond the product page
A separate frontend must still carry selected items correctly into the cart and reach the intended checkout. Customer sign-in and the views permitted there are part of the overall task. If an interface changes, a page that looks unchanged can still malfunction.
The merchant would therefore need to establish how product changes are checked in preview and published views, and who investigates a failure at the checkout handover. This architecture adds responsibility that a design mockup cannot demonstrate.
A comparative prototype should show the same customer task in the theme and custom frontend, including a changed product detail. If the difference is only colour and spacing, the theme remains a suitable starting point. If the prototype demonstrates a needed activity that was previously inadequately supported, the added operational work can be weighed against that concrete benefit.
Sources
Read more
All articles
E-Commerce with ASES
Online shops, marketplaces and B2B portals