Retail

Retail is the simplest block: a finished physical thing moves from you to the customer, and the thing you sell is the thing you count off the shelf. Clothes, electronics, books, packaged goods, hardware. You model it as a product with its inventory tracked one-to-one (one sale = one unit deducted).

The shape of a retail product

A product is the thing a shopper recognises and shops for: "Cotton T-Shirt", "Wireless Earbuds". Every product has:

• A name, description, image(s), and a base price.
• One or more variants — the specific forms you actually sell.

If your product comes one way only (a single mug), it has one implicit variant and you never think about variants again. If it comes in sizes, colours, or other forms, you describe those with axes and variants.

Variants, axes, and values

Three words, one simple idea:

• An axis is a dimension the product varies along — "Size", "Colour", "Storage".
• A value is one option on an axis — "Large", "Red", "256GB".
• A variant is one real combination you sell — "Red / Large".

Product: "Cotton T-Shirt"   base price 20.00
├── Axis "Colour":  Red, Blue
├── Axis "Size":    S, M, L
└── Variants you actually stock:
      Red / S    +0.00
      Red / M    +0.00
      Blue / L   +2.00   ← bigger sizes cost a little more

Key points:

• You don't create every combination. Three colours × four sizes is twelve possible variants, but you only create the ones you really stock. Create Red/S and Blue/L; skip the rest if you don't carry them.
• Prices are relative. A variant doesn't restate the whole price; it carries the difference from the base. "Large +2.00" means base 20.00 → 22.00. Change the base price and every variant follows.
• Each variant can have its own SKU, barcode, images, and a flag for which one is preselected on the storefront.

How variants load (a performance setting)

There is no limit on the number of variants a product can have. This setting only controls how they load, for performance — it is not a cap.

Default to loading all at once. Switch to on-demand when the combination count gets large; it handles hundreds of variants comfortably. The ~50 figure is just the sensible point to switch loading strategy, not a ceiling on how many you can sell.

Stock: what you sell is what you count

In retail, one sale deducts one unit. Each variant maps to one inventory item, usually matched by SKU — set the variant's SKU to the inventory SKU and stock decrements automatically on each sale.

Under the hood this uses the same "recipe" mechanism that food uses, but for retail it collapses to the trivial case: one unit, zero waste. You don't configure a recipe for retail; matching SKUs is enough. (This shared mechanism is why a business can be part retail and part food without two separate systems.)

Stock is tracked per variant, and per location if you have several. A few related fields:

Other fields worth knowing

When to use variants, and when not

This is the most common retail modelling mistake, so be deliberate.

Use variants when the items are the same product in interchangeable forms. The customer wants "this jacket" and then chooses size and colour. The forms share a name, description, images, and category. Sizes and colours of one garment, storage tiers of one phone, scents of one candle.

Use separate products when the items are genuinely different things a shopper compares side by side. A t-shirt and a hoodie are not variants of each other, even from the same brand. A 13" and 15" laptop might be variants (same model, two sizes) or separate products (different models) — decide by whether the customer experiences them as one product with a choice, or two products to compare.

Worked examples

A clothing line. Each garment is its own product. "Colour" and "Size" axes. Create the in-stock combinations, each with a matching SKU. Larger sizes that cost more carry a +price on those variants. "New In" and "Sale" are collections, not categories.

A phone. One product, axes "Storage" and "Colour". Many combinations → switch to load-on-demand. Each variant has its own SKU; serial numbers are tracked in inventory, not as variants.

A single artwork. One product, one variant, quantity 1, condition as appropriate. No axes.

A wholesale-only case of wine. A product with a minimum order quantity so it can't be bought as a single bottle.

Mistakes to avoid

• Making unrelated products into variants to "keep them together". Use a collection for that instead.
• One variant per serial number. Serials live in inventory batches; the variant is the model/configuration.
• A gift set as a variant. A set of products sold together is a bundle.
• Forgetting SKUs, so stock can't match and never decrements.

Common questions

Do prices have to differ per variant? No. Most variants cost the same as the base (difference of 0). Only set a difference where a form genuinely costs more or less.

Can different variants have different images? Yes — each variant can carry its own images, so picking "Red" shows the red photos.

How do I handle the same item in multiple shops? Stock and price can be set per location. The product is one; its availability and pricing vary by location.

What about a product that's sometimes made to order? If selling it consumes tracked ingredients, it's food, not retail — even if it looks like a packaged good. If it's just "we'll restock", keep it retail and enable backorder.

Next: Food for things you make, or Pricing & extras for add-ons, custom fields, and tax.