The situation
BrillianceCarat sells lab-grown diamond jewellery — engagement rings, bands, earrings, pendants — manufactured and certified in house, shipped to buyers mostly in the US and UK.
Two things make this harder than a normal storefront. The first is that a customer buying a diamond is not buying a product in the way a customer buying a jumper is. The second is that the business does not only sell direct: there are people selling on its behalf, and they need to be paid for what they bring in.
A standard e-commerce build handles neither. It assumes a fixed SKU with a fixed price and one kind of buyer.
The question we asked
When someone says they want a 1.5 carat oval, are they buying a ring, or are they buying a stone?
They are buying the stone. The setting is how they carry it. That sounds like a distinction for a jeweller to care about, but it decides the entire data model — because if the stone is the product, then the thing on the shelf is not a finished piece at all. It is a setting, waiting for a stone the customer has not picked yet.
The second question was for the other side of the business: when a partner sends a customer, what does the partner actually need — access, or credit?
What we decided
A piece is a setting plus a stone, chosen separately. The catalogue lists settings; the customer picks the shape, then chooses the stone against the familiar criteria, and the price resolves from the combination.
The alternative was a fixed catalogue of finished pieces. It is far simpler to build and it fails in one of two ways: either you list every setting against every stone and drown in SKUs, or you pick the combinations for the customer and tell someone spending four figures which diamond they are allowed to have.
On the partner side we decided partners get attribution codes, not accounts. A partner promotes with a unique code and earns on what it brings in. They never need a login to the store, which means the network can grow without every new partner becoming a permissions question.
What we built
The storefront, with shape-first navigation across the ten cuts buyers actually search by — round, oval, princess, cushion, emerald, pear, marquise, radiant, asscher, heart — and filtering by metal, style and price on top of it.
Pricing is multi-currency, and the content shown adapts to the buyer's country, so a UK buyer is not reading American shipping terms in dollars. An offers and coupon engine sits over the pricing rather than beside it, so a discount resolves correctly against a price that was itself assembled from a setting and a stone.
And the Sales Partner Program: apply, get approved, promote with a unique code, earn on what it converts.
What happened
The store is live and serving several countries from one build, with the partner programme running alongside it.
We are not publishing revenue or conversion figures. They are BrillianceCarat's to share or not, and a number we cannot show the working for is not evidence.
What we would not build
A live market price feed. Lab-grown diamond prices have moved steadily, and wiring the storefront directly to a market rate sounds like diligence. In practice it means a price that can change while a customer is deciding, and a coupon engine that has to reason about a moving base. Prices are set deliberately and changed deliberately.
We also left out a build-your-own-ring designer. It demos well. It converts badly, and it promises a manufacturing path that a considered setting-plus-stone flow already covers without the promise.