Unified Commerce Platform for Habbal Jewellery
Abdullah Amir
Habbal Jewellery does not run one business. It runs seven, and each has its own buyers, its own pricing logic and its own idea of what an order is. We built all of them on a single Medusa.js backbone across six months.
Medusa.js
commerce backbone, custom around it
7
modules, each with its own buyer and pricing
sprints across six months
STOREFRONT
› THE BRIEF
A jewellery business that a storefront cannot describe.
Most jewellery retailers sell finished pieces to consumers. Habbal does that, and then keeps going: brokering sales between third parties, running B2B auctions, selling loose diamonds, taking bespoke commissions, and wholesaling to trade buyers.
Each of those is a different transaction. A consumer buying a ring and a trade buyer bidding in an auction share almost nothing: not the pricing rules, not the checkout, not the definition of stock, not who is allowed to see what. Off-the-shelf commerce platforms model the first one well and the other six badly or not at all.
The requirement was one platform, one catalogue and one admin, with seven ways of transacting on top of it. That is a Commerce Lab problem and a Dev Lab problem at the same time, which is why the sprint team drew from both.
› WHAT WE BUILT
Seven modules, one backbone
Medusa.js handles catalogue, orders and inventory. Everything that makes each module different from the others was built around it.
D2C
D2C Commerce
Finished pieces sold direct to consumers. The conventional storefront, and the only module a standard platform would have covered on its own.
A marketplace where Habbal sits between buyer and seller on transactions it brokers rather than owns outright.
Loose stones sold on their own terms, where the buying decision is specification rather than design.
Timed B2B bidding for trade buyers, with its own rules for who can see a lot and what a winning bid commits them to.
Bespoke commissions that start as a conversation rather than a product page and become an order later. It also cater to audience who already have a sentimental piece that they want to replicate in other jewellery items.
Per-item configuration flows that Habbal defines themselves from the admin. The hardest module, and the one described below.
Trade pricing, trade quantities and trade accounts, running against the same catalogue as the consumer storefront and more.
› THE HARD PART
The configurator had to be built by the client, not by us.
Configurable Jewellery Request was the module that set the architecture for everything else. A ring, a bracelet and a pendant do not share a set of options, and there is no fixed list of options to hard-code. Every item needs its own configuration flow, and Habbal needed to create those flows themselves, from the admin, without a developer.
A customer answers a short sequence of questions about the piece they want and sees a price. They should never be aware that the questions were assembled from a definition somebody wrote in an admin panel that morning.
Nothing about the flow is known at build time. The backend validates attribute sets it has never seen, and the frontend renders a form it was not written for, with pricing that depends on the combination of answers.
Adding a new configurable item is an admin task, not a release.
CUSTOMER SIDE
Configurator, mid-flow
Admin flow builder
› PLATFORM
Why Medusa rather than a hosted platform
A hosted platform gives you a checkout and takes the data model in exchange. That trade is worth making for a single D2C store. It is the wrong trade when four of your seven modules are transactions the platform has no concept of.
Medusa gave us the parts that are the same everywhere — catalogue, inventory, orders, payments — as code we could extend rather than configuration we had to work around. Auctions, brokered sales and configurable requests were built as modules against that core instead of as workarounds on top of a checkout designed for something else.
The cost is that we owned more of the stack, which is real and worth stating. It is the reason this was twelve sprints rather than four.
› OUTCOME
What Habbal can do now that they could not before
Not a conversion figure. For a build like this the honest outcome is capability: things that were impossible or manual before, and are neither now.
Habbal defines the flow, the options and the attributes in the admin, and the piece goes live. No ticket, no developer, no release. The system stops depending on the agency that built it.
Consumer orders, brokered sales, diamond sales, auctions, commissions, configured requests and wholesale all read from the same stock and the same admin. The conventional route would have been three systems and a reconciliation problem.
Auctions and wholesale were relationship-and-phone business before. They now run on the platform, with their own access rules, alongside the consumer store rather than beside it in a spreadsheet.
“We do not sell the way an ordinary shop sells. Auctions, wholesale, brokered sales and bespoke commissions all had to work, and everyone we spoke to before wanted to build us four separate systems. What I did not expect is that I can set up a new configurable piece myself, in a morning, without asking anyone.”
Firas HabbalOwner, Habbal Jewellery
If your business does not fit a standard checkout, that is the conversation to have on the call.
Like this project
Posted Sep 18, 2026
Developed a unified commerce platform for Habbal Jewellery's unique transactions.
