Product Variant or Order Personalisation? Decide Before Building a Configurator

2026-10-24

Use a product variant when a choice identifies a version of a product that your business needs to manage separately. Use an order-specific detail for information that belongs to that particular purchase, such as the wording of an engraving. A selector and a text box may look like similar additions to a product page, but they should not automatically create the same kind of record.

This guide concerns product and order structure for a shop or ordering app, not whether to choose Shopify or a custom platform. The recommendations are commissioning guidance; confirm the chosen implementation with your developer.

Ask what the warehouse would recognise

Does choosing a value select a different item to pick, stock or price? If so, it is a strong candidate for a variant. In a hypothetical stationery shop, a blue notebook and a red notebook may be separately stocked versions. The customer's requested name on the cover is different: it tells production what to do for that order.

Shopify's ProductVariant reference provides a concrete example. It describes versions distinguished by options such as size or colour, and lists inventory tracking, unique pricing and SKU assignment among variant uses. Its Liquid line_item reference separately shows capturing engraving text as a line-item property. These sources demonstrate the distinction in Shopify, not a universal rule for every catalogue.

Do not make each customer's name a permanent catalogue option merely because the name is selected during ordering. Conversely, a free-text colour request should not stand in for a separately managed colour variant if staff must pick the exact stocked item.

Model combinations that you can actually supply

List the supported combinations before drawing the selector. If a material is available only with one finish, decide how an incompatible choice is explained. A combination your business does not sell is different from a valid variant that is temporarily out of stock.

For a custom configurator, require the saved order to be checked against the authoritative combination rules, not just the choices displayed in the browser. Decide what happens when availability or catalogue rules change while a customer is choosing. A reassuring screen should not silently save an impossible product.

Avoid assuming that every additional option needs a new variant. Explain the operational reason for each distinction. If the combinations become difficult to maintain, simplify the offer or discuss a dedicated configuration model; do not promise that a basic variants feature solves every manufacturing constraint.

Give personalisation its own production rules

Define which details staff need: exact text, permitted characters, length, placement and whether a proof must be approved. Separate an optional gift message from an instruction that blocks production until clarified.

If personalisation changes the price, specify that charge explicitly. Merely collecting text does not establish how an extra fee is calculated or collected. Likewise, a preview of lettering is not automatically an approved production proof. Decide what the customer is confirming and which version the team must use.

Keep order-specific instructions attached to the correct line. Two notebooks with different names should not lose that distinction when added to the basket, edited or sent to production. Ask whether otherwise identical personalised lines merge, and define the intended result.

Preserve what was agreed

Decide which product description, selected options, personalisation and agreed price are retained with the accepted order. Renaming a catalogue option later should not silently rewrite what production believes the customer ordered. Corrections after acceptance need an explicit process, particularly if work has already started.

For a repeat-order feature, decide whether old personalisation is copied, shown for review or cleared. Reusing the product is not necessarily permission to reuse somebody's name or message. Apply your agreed data-retention and access policy to those order details.

Ask for a demonstrable handover to production

Put these cases in the acceptance brief:

Staff can distinguish a stocked variant from purchase-specific instructions.
An unsupported combination cannot become an accepted order through another interface.
A temporarily unavailable variant is not described as a nonexistent combination.
Two otherwise identical items with different personalisation retain the intended separate instructions.
Any personalisation fee and proof-approval step follow the agreed rules.
Catalogue changes do not silently alter the accepted production instruction.
Editing and repeating an order handle personalisation deliberately.

When planning an ordering site or custom app, bring a small set of actual product choices and harmless sample instructions. The useful decision is which choices change the managed product and which describe work for one order.

Sources and scope

Shopify, ProductVariant: https://shopify.dev/docs/api/admin-graphql/latest/objects/ProductVariant

Shopify, Liquid line_item: https://shopify.dev/docs/api/liquid/objects/line_item

The references support the variant examples and the collection of engraving text as a line-item property. Combination validation, pricing, production proofs, historical snapshots and repeat-order behaviour above are proposed requirements, not verified platform guarantees.