Engineering5 min read
Headless Shopify for a multi-brand marketplace
Four years on one jewellery platform: Shopify behind a custom storefront, a brand-facing dashboard, and what a long support relationship actually looks like.
Fine Matter sells fine jewellery from independent jewellers. Not one brand with a catalogue, but a platform: 94 makers at the time of writing, each with their own pieces, their own identity, and their own view of how those pieces are selling.
Smart-UI has built and supported it since 2022. This is what the architecture is, why it is shaped that way, and what four years on one system actually involves, because the build is the short part.
Shopify behind a custom storefront, not a Shopify theme
The commerce engine is Shopify. The storefront is not.
Browsing, editorial content and every brand and product page are a custom front end built in Gatsby and React, with Prismic behind the editorial side and CloudFront serving it. When a visitor adds something to the basket they move to Shopify, which owns the cart, the checkout, payments and the order record.
That split is the whole design decision, so it is worth being plain about the trade.
What Shopify is excellent at is the part nobody should rebuild. Payments, tax, fraud checks, PCI scope, the order lifecycle, the admin that a non technical team already knows how to use. Writing your own checkout is a way to spend a year discovering why Shopify costs what it costs.
What a theme cannot do is everything in front of the basket when the business is not a single brand. A multi-brand platform needs its own content model, its own navigation, editorial pages that are not products, and a visual identity that belongs to the platform rather than to a template. Push that through a theme and you spend the next three years fighting the theme.
So: Shopify where Shopify wins, custom where the business is actually different.
The part Shopify does not do: the brands
The second system is the one you cannot see from the storefront.
Each brand on the platform needs more than a product listing. They need to place orders with the platform, see what is selling, and have numbers they can act on without emailing someone for a spreadsheet. None of that is a storefront feature, and none of it fits inside Shopify's own admin, which is built around one merchant rather than many.
That is a custom backend with its own dashboard: brand accounts, ordering between the brands and the platform, and reporting that each side reads differently. The platform needs the view across all brands. A brand needs only its own, and must not see anyone else's.
The general shape, for anyone weighing the same decision: the commerce platform owns the transaction, and a service you control owns the relationships. Trying to model a multi-vendor relationship inside a single-merchant commerce platform is where these projects usually get stuck.
What four years of support actually means
The architecture diagram is the easy part to publish. The honest version of a long engagement is quieter than that.
Most of it is not new features. It is a payment provider changing an API, a Shopify version deprecating a field, a dependency with a CVE, a theme update on the checkout side that moves something, an image CDN changing its behaviour. None of this appears on a roadmap and all of it has to be absorbed.
The value compounds in the least visible place. After four years the engineers know why a particular rule exists in the ordering logic, which brands have exceptions, and which piece of the content model will break if you touch it. That knowledge is the reason a change takes two days instead of two weeks, and it is exactly what a rotating supplier can never accumulate. It is also the single strongest argument for keeping the same people on an account, which we have written about separately in how to choose a white label development partner.
Nobody notices the good quarters. A support relationship is judged on the bad week, so the work that matters is the work that prevents one: dependency updates taken before they are urgent, monitoring on the paths that carry money, and a staging environment that actually resembles production.
What we would tell someone starting this
Do not rebuild the checkout. If your reason for going headless is the checkout, go back and check it, because that is the part you most want to keep.
Decide where the source of truth lives before you build. Products in Shopify, editorial in the CMS, brand relationships in your own service. Write it down. Every painful week on a composable stack traces back to two systems both believing they own the same record.
Budget for the second system. Teams scope the storefront and forget that the thing making the business work is the backend nobody sees. On a multi-brand platform that backend is not an extra, it is the product.
Assume the relationship is long. A commerce platform is not a project with a completion date. Price it, staff it and choose a partner on that basis.
The stack, in one place
| Layer | What runs it |
|---|---|
| Storefront | Gatsby, React, deployed behind CloudFront |
| Editorial content | Prismic |
| Commerce, cart, checkout, payments | Shopify |
| Brand ordering, dashboard, statistics | Custom backend with its own data model |
| Engagement | Continuous support since 2022 |
The full case study, with the architecture and the process, is at Fine Matter.
If you are building something with the same shape, a commerce platform plus a side the platform was never designed for, tell us what you are building and we will say plainly which half belongs where.