Skip to content
Luxury Perfumes logo

Luxury Perfumes

Live

E-commerce for designer and niche fragrance

Luxury Perfumes is a fragrance store we designed and built, now live at luxuryperfumespk.com. It runs on an open-source commerce engine rather than a hosted store platform, because the rules that make this business work are exactly the ones a stock checkout cannot express.

The problem

A fragrance store sells two things that look alike and behave nothing alike. A full bottle is a unit: sealed, counted, sold. A decant is a few millilitres poured from a bottle that is already open, so every decant sold changes what every other size of that fragrance can still offer. Store platforms count units. They have no idea that a 5ml and a 10ml decant are drawing on the same bottle.

Payment is the second mismatch. The store takes bank transfer, not cards, so an order is placed when the customer commits and only becomes paid when the money arrives and the owner confirms it. Most checkouts assume those are the same moment.

The hard part

Decant prices are derived, never typed. Each one is the source bottle's price per millilitre, multiplied by the decant size and a size markup, plus a flat atomiser fee, rounded to a clean price. The source is the largest full bottle of the same concentration, and on a tie the cheaper bottle wins, so a duplicate catalogue row can never push a price up. Sizes, markups and fees are set in the admin, the pricing code hard-codes none of them, and testers and gift sets never get decants.

Stock is checked across the whole cart rather than line by line. Two decants of one fragrance need their millilitres added together before anyone can say whether the open bottle has enough left for both.

What we built

A deliberately slim Medusa 2 backend: one instance with no separate cache or queue in production, custom modules for fragrance details, decant sizes, checkout settings and order access, and its own payment and delivery providers. Delivery is quoted on the server from parcel weight, packaging included, against a rate table the owner edits; whatever amount a browser sends is ignored.

The details that decide whether a small store survives its first bad actor are built in from the start. The order page opens with a one-time access token of which only a SHA-256 hash is stored, so a database leak opens nobody's order. Payment receipts are identified by their first bytes rather than the file name or type the browser claims, capped at 5 MB and rate limited. Unpaid orders can be cancelled automatically after a set time, and an order with a receipt uploaded never is.

The catalogue arrives as unpublished drafts carrying facts only (brand, notes, perfumer, launch year), so the owner prices, sizes and publishes rather than typing each entry by hand. The storefront and its identity, a crystal flacon mark in deep teal and champagne gold, were designed alongside the engine.

Why it matters to a client

Most businesses that outgrow a hosted store do so over one rule the platform cannot express. Here it is millilitres and manual payment confirmation; for someone else it is bundles, deposits or trade pricing. The approach does not change: keep the commerce engine standard, put the one unusual rule in a small module with its own tests, and keep everything around it boring.

Want something like this built?

We take on a small number of product builds each year, from first prototype to a system that runs itself. Tell us what you have in mind.