Take one ring. Offer it in 14KT and 18KT. In yellow, white and rose. In sixteen sizes. With two diamond qualities.

That is one design and one hundred and ninety-two legitimate products, each with its own weight, its own making charge and its own price that changes with the morning rate. None of them is a variation in colour the way a t-shirt is. Each one is a different quantity of gold.

Generic ecommerce platforms were built for the t-shirt.

Where the multiplication comes from

Start with a single ring design.

It is available in two gold purities: 14KT and 18KT. Customers can choose yellow, white or rose gold. There are sixteen ring sizes and two diamond quality options.

The combinations multiply quickly:

2 purities × 3 colours × 16 sizes × 2 diamond qualities = 192 possible configurations.

That is before accounting for different diamond carat weights, individual stone specifications, design revisions or made-to-order requirements.

Not every combination will necessarily be valid. A particular design may not support every purity or stone option, and some configurations may be available only on request. But the underlying problem remains: a single design can represent a large number of commercially distinct products.

Now consider what happens when the catalogue expands to hundreds or thousands of designs.

If every possible combination is treated as a separate, manually maintained product, the catalogue becomes difficult to manage. Teams must maintain prices, weights, SKUs, stock status and product attributes across an expanding set of records.

If the combinations are not modelled properly, the alternative is just as problematic. Customers see incomplete options, prices fail to reflect their selections, or store teams have to confirm details manually.

The challenge is not simply the number of combinations. It is the amount of business logic attached to each one.

Why each combination is a different weight, not a different label

In conventional ecommerce, a variant often changes the appearance of a product without fundamentally changing its pricing model. In jewellery, a selection can change the material composition, physical weight and value of the item itself.

Consider ring size.

A size 16 ring may require more metal than a size 10 ring of the same design. The exact difference depends on the design and manufacturing process, but the important point is that the weight is not necessarily constant across sizes.

Purity introduces another variable. Fourteen-karat and eighteen-karat gold contain different proportions of gold and other metals. Their applicable metal rates therefore differ, and the final price must reflect the selected purity.

Diamond quality adds another layer. Two rings with the same design and metal specifications can have different prices because their stones differ in quality, weight or other characteristics.

The final price is consequently derived from the selected configuration, not simply inherited from the master product.

A jewellery pricing engine needs to understand the relationship between the product's specifications and the jeweller's pricing rules. Depending on the product, that can include:

• The applicable metal rate and purity.
• The estimated or actual metal weight.
• The making charge calculation.
• Diamond or gemstone specifications and value.
• Other applicable charges and taxes.

There is an important distinction between estimated and actual weight, too. A made-to-order ring may be priced using an estimated weight initially, with the final amount confirmed after manufacturing and weighing.

A system that treats both values as interchangeable risks creating discrepancies between the product page, the order and the final invoice.

What a generic platform does with this

A conventional variant model can work well when product combinations have fixed prices and predictable stock. The difficulty begins when each configuration depends on changing rates, physical specifications and jewellery-specific pricing rules.

Several failure modes tend to appear.

Manual price entry per SKU. Every configuration receives its own manually entered price. When the gold rate changes, someone must identify and update the affected products. The larger the catalogue, the harder it becomes to ensure that every price is current.

Variant limits and catalogue workarounds. When a product model cannot comfortably represent the required attributes, teams may split one design into multiple listings or create additional products to work around the limitations. This can fragment product information and complicate catalogue maintenance.

Stale prices. A rate update may reach one part of the system but not another. A product listing, cart or checkout can then display inconsistent prices unless the platform has a clear recalculation and validation process.

Disconnected inventory. A size or stone configuration may be available in one store but not another. If inventory is tracked only at the master-product level, the website may show availability that does not reflect the actual piece or fulfilment location.

Inconsistent customer experience. A customer selects a ring, changes the purity, and sees a price that does not change correctly. They then contact the store to verify the amount. The technology has transferred the complexity of the catalogue to the customer.

None of these problems necessarily means a conventional platform cannot support jewellery. Some can be addressed through extensions, custom development or integrations. The question is whether the underlying architecture can represent jewellery-specific rules reliably without creating an unmanageable maintenance burden.

The making charge problem

Making charges are where a simple product-variant model often starts to break down.

Jewellers do not necessarily calculate making charges in the same way across every design or product category. Depending on the business and its pricing policy, charges may be calculated as a percentage of metal value, a rate per gram, a flat amount, or another defined method.

Consider a ring with a metal value of ₹40,000.

If the making charge is 10% of metal value, the charge is ₹4,000.

If the making charge is ₹800 per gram and the ring weighs 5 grams, the charge is also ₹4,000.

The resulting amounts are identical in this example, but the calculation rules are different. If the weight or metal value changes, the two methods may produce different results.

The complexity increases when making charges vary by design, product category, manufacturing technique or store-specific commercial policy.

A percentage-based rule cannot be substituted blindly for a per-gram rule. Nor should every product inherit the same flat charge simply because that is the easiest field to maintain.

This logic belongs in a pricing rules engine, where each applicable rule has a clear scope, calculation method and priority.

A spreadsheet can be useful for maintaining rates or reviewing calculations. It becomes a fragile source of truth when the business depends on multiple interacting rules, frequent changes and consistent calculations across product pages, carts, POS systems and orders.

The platform needs to know which rule applies, what inputs it requires and when the result must be recalculated.

Stones, certificates and the fields nobody models

A jewellery catalogue also needs to represent information that does not fit neatly into a basic set of variant dropdowns.

For diamonds, relevant attributes can include carat weight, colour, clarity, cut and certification details. Other gemstones may require their own specifications.

These fields are not all interchangeable product options. Some describe a general product configuration, while others identify a particular physical stone or finished piece.

That distinction matters when a certificate belongs to an individual diamond rather than to every item sold under a particular SKU.

Imagine a ring design that uses a certified diamond. Two physical rings may share the same design and general specifications, yet contain different individual stones, each with its own certificate number.

If the certificate is stored only against the master product, the system may display the wrong certificate for the piece being sold.

A more dependable catalogue separates three layers of information:

• Master design: Shared information such as the design name, description, photographs and general specifications.
• Product configuration: The selected purity, size, finish, stone characteristics and other attributes defining a purchasable configuration.
• Individual item or stone: Piece-specific details such as actual weight, serial or inventory identifier, and a certificate linked to the relevant physical stone where applicable.

Not every business needs all three layers for every product. A mass-produced fashion accessory and a one-of-a-kind certified diamond ring have different requirements.

The architecture should accommodate those differences without forcing every product into the same data structure.

Configure, do not enumerate

The architectural answer is to store the rules and product attributes needed to create a valid configuration, rather than manually creating and maintaining a separate record for every theoretical combination.

This approach is commonly described as rule-based product configuration.

The master design stores shared information. Configuration rules define which combinations are allowed. The pricing engine calculates the applicable price using the selected attributes, current rates and relevant commercial rules.

For example, when a customer chooses an 18KT ring in size 16 with a particular diamond quality, the platform should:

1. Validate that the requested combination is supported.
2. Retrieve the relevant product and pricing attributes.
3. Apply the correct metal rate and making charge rules.
4. Include the applicable stone value and other price components.
5. Return the calculated price and relevant weight information.
6. Check availability or manufacturing requirements for that configuration.

The result can be presented as one product page, even though the underlying configuration has its own specifications and commercial implications.

This does not mean that every possible configuration should exist only as an abstract calculation. Real inventory still needs to be represented accurately. A stocked ring, a made-to-order configuration and an individually certified diamond each require the appropriate records and fulfilment logic.

The principle is to avoid unnecessary duplication while preserving the information required to sell and deliver the actual product.

The morning-rate test

A practical way to evaluate this architecture is to consider what happens when the applicable gold rate changes at 09:47.

If prices are calculated dynamically, the system should use a clearly defined rate source, effective time and pricing policy. Relevant product prices can then be recalculated or refreshed according to the business's rules.

But changing the rate is only part of the problem. What happens to products already in a customer's cart? Does checkout validate the latest permitted price? Are confirmed orders protected from subsequent changes? Do connected stores and channels receive consistent updates?

These questions require explicit rules.

A dynamic pricing engine should not simply change numbers whenever a rate changes. It should manage when rates become effective, which transactions use them and how price changes are communicated to customers.

That is what separates a pricing calculation from a reliable jewellery commerce system.

What this means for the product page

The customer should not have to understand the architecture behind the catalogue.

They should be able to select a size, purity or stone option and see the relevant information update without being redirected through a maze of nearly identical product listings.

At a minimum, the product page should handle four things together.

Price. The displayed amount should reflect the selected configuration and the applicable pricing rules.

Weight and specifications. Where the weight is estimated or varies by size, the page should communicate that clearly. Purity and stone details should correspond to the actual selection.

Availability. The page should distinguish between an item that is ready to ship, a configuration that must be manufactured, and an option that is unavailable.

Cart and checkout consistency. The selected configuration and its specifications should persist when the customer adds the product to the cart. Before an order is confirmed, the platform should validate the price according to the store's pricing policy.

A page that updates the price but leaves the weight unchanged is not solving the problem. Neither is a page that calculates the right amount but lets an unavailable configuration proceed to checkout.

The selected variant, price and fulfilment information must work as one coherent experience.

For jewellery brands, that is not merely a user-interface improvement. It is how the website communicates that the product being purchased is the product the customer actually selected.

Questions to ask a platform before you sign

Before committing to an ecommerce platform, jewellery founders and ecommerce managers should ask questions that reveal how the system handles real product and pricing complexity.

1. How are prices derived?

Ask whether prices are manually maintained per SKU or calculated from configurable rules covering weight, purity, making charges, stones and other relevant components.

2. What happens when the gold rate changes at 09:47?

Ask how new rates become effective, how prices are recalculated, and what happens to existing carts, checkout sessions and confirmed orders.

3. How does the platform handle 192 possible configurations?

Ask how valid combinations are defined, whether every combination must be created manually, and how the system handles combinations that are unavailable or not supported by the design.

4. Can making charge rules differ by design or store?

Ask whether the system supports percentage-based, per-gram and flat charges, including clearly defined rules for when each method applies.

5. How are actual inventory and certified stones represented?

Ask whether the platform can distinguish between a master design, a configuration and an individual physical item, including piece-specific weights and certificates where required.

6. What happens when a selected configuration is unavailable?

Ask whether the website can offer a valid alternative, explain a made-to-order option or prevent an unavailable combination from being purchased.

7. How does pricing stay consistent across the website and POS?

Ask which system owns the pricing rules, how updates are synchronised, and how conflicts or failed updates are handled.

8. What happens as the catalogue grows?

Ask the vendor to demonstrate a representative product with multiple attributes and changing rates. Evaluate not just the number of variants supported, but the effort required to maintain prices, inventory and product data as the catalogue expands.

A useful demonstration should go beyond showing a dropdown that changes a price. It should show where that price came from, which rules were applied and how the result remains consistent through checkout.

Frequently asked questions

How many variants can one jewellery product have?

The number depends on the valid combinations of attributes such as purity, colour, size and stone quality. A ring with two purities, three colours, sixteen sizes and two diamond qualities has up to 192 possible configurations. The actual number of sellable variants may be lower if certain combinations are unsupported or unavailable.

Why cannot jewellery prices be entered manually per variant?

Manual pricing can work for a small, stable catalogue, but it becomes difficult to maintain when prices depend on changing gold rates, weights, making charges and stone specifications. Each update creates opportunities for inconsistent prices across product pages, carts and sales channels. Rule-based pricing reduces this manual burden while making calculations more consistent.

How should making charges be modelled in a jewellery catalogue?

Making charges should be represented as configurable pricing rules that support the methods used by the jeweller, such as percentage-based, per-gram or flat charges. The rules should define their applicable products or categories, calculation inputs and precedence where multiple rules could apply. This keeps pricing logic consistent and easier to maintain than manually storing the result for every possible configuration.

Do jewellery variants need separate product pages for SEO?

Not necessarily. When variants belong to the same design and serve substantially the same search intent, a single product page with clear configuration options is often appropriate. Separate pages may be useful when variants have meaningfully different product identities or distinct search demand, but they should provide unique value rather than duplicate nearly identical content. Canonical tags, indexation rules and structured product data should reflect the chosen catalogue strategy.

One design. Many configurations. One system that understands the difference.

A ring is not a fixed-price product with a few cosmetic options. Its value can depend on the amount and purity of metal, the selected stones, manufacturing charges and the individual specifications of the finished piece.

As a jewellery catalogue grows, those variables multiply. Managing every possible combination manually creates work that becomes increasingly difficult to maintain.

The answer is not simply to add more product rows. It is to model the design, configuration, pricing rules and physical inventory correctly, then connect those elements through a consistent commerce architecture.

That is how a jewellery brand can offer more choice without making its catalogue harder to manage.

One ring may be one design. It is never necessarily one price.