Most conversations about product configurators start with colour. A shopper picks a finish, the render updates, everyone nods. That is the easy version.
The harder version is configuration where options affect each other: you cannot select the performance wheel package without the sport suspension, the two interior bundles are mutually exclusive, and the chassis type is mandatory before a price can be quoted at all. This is option configuration, and it is a different engineering problem from colour swapping.
This article covers what changes when a catalog has real option logic, which product types run into it, and how to tell whether your store needs a rules engine rather than a swatch.
Where option configuration starts
Colour switching has no rules. Every colour is available on every product, and changing one choice never disables another. The moment that stops being true, you are in option-configuration territory.
Five behaviours define it:
Dependencies. Selecting one option unlocks another. The performance wheel package only becomes available after the sport suspension is chosen. A shopper who cannot see that relationship has to read a spec sheet to discover it.
Exclusions. Some combinations cannot coexist. When a shopper picks interior bundle A, bundle B must visibly become unavailable — not silently rejected at checkout. Buyers who build a combination and only discover the conflict at the cart are buyers who leave.
Required selections. In industrial and automotive catalogs, certain choices are not optional. The chassis type is mandatory; without it no price can be calculated. A configurator that renders beautifully but cannot express “you must choose this” is incomplete.
Live pricing. Individual option prices are rarely the whole story. Combination discounts, tiered pricing and promotional rules all affect what the buyer actually pays. The price has to recalculate on each interaction, because a shopper who is shown a price that changes later stops trusting the page.
Downstream output. The configuration has to leave the storefront as something production can use — a bill of materials, a specification record, a manufacturing parameter set. If a human has to re-key that configuration into a system, the errors happen at exactly that handover.
A flat form can technically capture all five. What it cannot do is show the buyer what they are building. That is the case for making it 3D: every option added or removed gets immediate visual confirmation, and the configuration stops being an abstraction.
Product types that run into this
Automotive and aftermarket parts. Fitment is the whole problem. A buyer’s first question is “will this fit my vehicle”, and the second is “what does the combination look like”. Both are answerable in a configurator and neither is answerable in a photograph.
Industrial equipment and machinery. Selection parameters are numerous, accessory combinations compound, and quotes depend on the configuration. Sales teams currently spend their time translating configuration logic out of spreadsheets and PDFs. A configurator makes that logic the interface.
Computers and electronics. Memory, storage, display and peripheral selections all interact, and compatibility checking is expected behaviour rather than a nice-to-have.
Modular furniture. Module sizes, orientation, material and accessory selection make this one of the most rule-heavy corners of the furniture category — see our notes on furniture configurators for how material rendering works in the same context.
Outdoor and sporting equipment. Accessory ecosystems are broad — mounts, storage, upgrade components — and every addition is a chance to raise order value, provided the shopper can see what they are adding.
How the engineering works
Three layers sit underneath a production-grade option configurator.
A data-driven rules engine. Dependencies, exclusions, required selections and default combinations are defined as data rather than hard-coded logic. This matters after launch, not before: when a product line changes, the rule change should be a configuration update rather than a software project.
Real-time pricing. Option prices, bundle discounts and tiered rules are evaluated on each interaction and the displayed price is recalculated immediately. Treating pricing as part of the rules engine rather than a separate calculation keeps the two consistent.
Production export. The finished configuration is structured for downstream systems — a bill of materials, a specification record, or a parameter set for manufacturing. Where a brand sells through dealers or distributors, this layer also removes the re-entry step that mis-specified orders come from.
We build these on WebGL, so they run in the browser without a plugin, and we build them per catalog rather than from a template. Per MDN’s WebGL documentation, WebGL support is present in all modern browsers, which means no app install stands between a buyer and the configuration.
Build approaches, honestly compared
Subscription apps. Fast to install, priced monthly, and limited by their template. Simple option sets work; genuine dependency and exclusion logic generally does not.
Enterprise CPQ platforms. Built for very large catalogs and complex pricing, licensed accordingly, and designed for organisations with the internal resources to operate them. For a mid-sized brand the overhead rarely justifies the fit.
Project-based custom development. The configurator is built around your actual rules and your actual catalog. You pay for the build rather than subscribing indefinitely, and the configuration data — including the production export — is yours. This is the route we take, and it is the right one when configuration logic is part of how you sell.
The honest limits
A configurator does not fix a catalog whose option logic is not yet understood. If your rules exist only in the heads of two salespeople, the first project deliverable is a written rule set, not a 3D model — and any studio that skips that step will produce something that looks right and configures wrong.
It also is not the right spend for a single-SKU product with no options. If a shopper’s only decision is quantity, a configurator adds cost and loading time without changing the purchase.
FAQ
What is the difference between an option configurator and a standard product configurator? A standard configurator centres on appearance — colour and material. An option configurator centres on logic: dependencies between choices, mutually exclusive combinations, mandatory selections, and pricing that recalculates as the configuration changes. It also typically outputs a production-ready specification.
Can it handle a catalog with hundreds of possible combinations? Yes. The combinations are resolved by the rules engine, not presented as a list. The shopper only ever sees the options that are currently valid given their choices.
Can pricing rules be complex? They can be. Tiered pricing, bundle discounts and promotional rules are all defined as data and evaluated live, so the price shown is the price that applies.
Does it work with Shopify? Yes. The configurator is a browser-native WebGL module that can be embedded on a product detail page, with configuration flowing into the cart and order. Shopify accepts GLB models up to 500 MB and generates USDZ automatically for iOS.
How long does a build take? It depends on the number of products and, more heavily, on how complicated the option logic turns out to be. We do not quote a duration before that logic is mapped, because the timeline is driven by rule complexity rather than by model count.
Next step
The useful first conversation is not about 3D. It is about your option logic: which choices depend on which, what cannot be combined, and what has to be selected before a quote is possible. Send us that, and we will tell you whether a configurator is the right answer — and what the build would involve if it is.