A product configurator is worth building when your products are assemblies with dependent options — where choosing one component changes what else is valid, and price has to recalculate as selections change. If your options are independent, like size or color that don’t affect each other, you don’t need a configurator. You need variants, and every ecommerce platform already handles those natively.
That distinction sounds abstract until you’ve lived on the wrong side of it. We learned it building for a client of ours, an Australian retailer selling automated gates and access control hardware — motors, tracks, sensors, brackets, and accessories that combine into kits, where not every combination is valid and price depends on what’s selected. Standard variants can’t express that. Their original WooCommerce store tried anyway, and it’s a useful case study in what breaks.
This is the first piece in a three-part series on this client’s build. Part two covers how we tracked what those configured kits actually contained, and part three covers whether pricing and quoting them needed dedicated CPQ software.
Key takeaways
- A configurator earns its cost when options are dependent, not independent. Size and color that don’t interact are a variants problem. Components that constrain each other and reprice as they’re chosen are a configurator problem.
- Our client’s configurator was custom-built, not a standard Odoo checkbox. Odoo’s native attribute system, like most platforms’, doesn’t ship a cross-attribute compatibility rules engine out of the box.
- WooCommerce has no native equivalent. Its core Variable Product type only handles flat attribute combinations; nested, rule-validated assemblies require stacking separate paid extensions.
- Shopify has a structural ceiling, not just a missing feature. Products are capped at three options regardless of variant count, and bundles can’t contain other bundles — we cover this in full in what an Odoo build for Shopify actually involves.
- Configurator work is scoped inside the standard implementation range, not billed separately — catalogue and pricing complexity is one of the six factors that moves you toward the top of that range.
- Not every catalogue needs this. If your options don’t constrain each other, a configurator is unnecessary cost and complexity.
What a product configurator actually is
A product configurator — sometimes marketed as configurator software or bundled into CPQ software — lets a customer or salesperson build a product from a set of dependent options, validating each choice against the ones already made and recalculating price as selections change. That’s different from product variants, which is what most ecommerce platforms mean by “configurable product” by default: a flat list of independent attributes like size and color, where every combination is equally valid and priced the same way relative to the base product.
The test is dependency. Ask whether choosing one option changes which other options are valid, or changes the price by more than a flat per-option surcharge. If the answer is no, you have a variants problem, and it’s already solved. If the answer is yes, you have a configurator problem, and it usually isn’t solved by whatever ecommerce platform you’re already on.
What this client’s build actually involved
Our client’s catalogue is built around configurable gate and access-control kits — motors, tracks, sensors, brackets, and accessories that customers combine to match a specific gate type and installation. Before migrating, their WooCommerce store ran a custom kit configurator and a growing set of third-party extensions to manage it, alongside separate tools for trade pricing and product content. As the catalogue and traffic grew, keeping those systems synchronized became a manual, ongoing job.
The migration to Odoo replaced that stack with a custom-built product configurator developed specifically for their kits. It supports nested components, dynamic selections, and real-time price recalculation, built natively inside Odoo’s database logic rather than as a bolted-on layer. Odoo’s pricelist and promotion engine is integrated directly into the configurator and checkout flow, so trade and retail customers see the correct price the moment they configure a product — no separate pricing system to keep in sync.
Be precise about what “custom-built” means here: this was development work, not a setting we switched on. Odoo’s standard product attribute system, like most platforms’, doesn’t ship a cross-attribute compatibility rules engine out of the box — there’s no native way to say, as a generic example, “if a customer picks a 3-phase motor, the starter option must be Soft-Start” without either custom development or a dedicated CPQ layer on top. What Odoo’s architecture gave us was a single database and a data model flexible enough to build that logic once, natively, rather than stitching together several separately-licensed plugins the way the original WooCommerce setup had to.
The migration also involved a custom text parser that imported their existing HTML-based product descriptions into Odoo without a full manual rewrite. Moving the configurator off third-party plugins had a measurable performance effect, documented in the same case study: desktop pages that previously took more than 4 seconds to reach Largest Contentful Paint now render in under 2.5 seconds, and mobile pages went from roughly half exceeding the 2.5-second threshold to 99% under it.
Where Shopify and WooCommerce structurally can’t do this
Neither of the two platforms this client could have chosen instead has a native way to model this.
WooCommerce’s core product system has no native path to it. Its built-in Variable Product type only handles flat attribute combinations — it isn’t built to model an assembly of dependent, nested components with conditional validation or price recalculation. That capability exists only through separate extensions such as Composite Products, Product Bundles, and Dynamic Pricing, each sold, configured, and maintained independently. Even the most capable of them, Composite Products, documents limits when a component is itself a variable product. That’s exactly the plugin stack this client’s original store was running, and exactly what became hard to maintain as the catalogue grew.
Shopify’s limit is structural rather than a missing feature. Products are capped at three options no matter how many variants Shopify allows, and Shopify’s own documentation states that bundles cannot contain other bundles. A configurator with several independent choices, or a kit assembled from sub-kits, has no native representation on the platform — workarounds exist, but each costs you something (the standard cart, the theme ecosystem, or access gated to enterprise plans). We cover those workarounds and their tradeoffs in full in what an Odoo build for Shopify actually involves; we won’t repeat that analysis here.
The common thread: this isn’t a platform maturity problem, it’s a data model problem. Shopify and WooCommerce were both built around a product-plus-variants model. A configurator needs a component-and-rules model. Bolting the second onto the first is what plugin stacks and structural caps both are, from different directions.
What a configurator adds to implementation cost
A configurator isn’t a separate line item on an Odoo quote — it’s scoped inside the implementation work itself. In our experience, Odoo ecommerce implementations run roughly $5,000 to $50,000 (USD), and the widest-effect variable is how much of the configuration your own team does rather than your size. Teams that configure Odoo themselves, with an agency bridging the gaps, typically land at $5,000–$10,000. Teams that hand the whole project over typically land at $10,000–$50,000.
Where configurator work specifically moves you inside that range: catalogue complexity is one of the six factors that pushes a project toward the top of it, and a rules-based configurator is catalogue complexity in its most concentrated form. A flat SKU list costs less to implement than a dependency network of components, even at a similar total SKU count — because someone has to encode the actual compatibility and pricing rules your business runs on, not just import a product list.
Two things specifically drive a configurator engagement toward the higher end of the range: how many components have to interact (a configurator with a handful of accessories is simpler than one with several layers of dependent choices), and whether your own team can define the rules precisely enough for someone else to build them. The second is the same “someone has to know all your workflows” constraint that governs Odoo pricing generally — a configurator just makes it concrete, because every rule has to come from somewhere.
When a configurator isn’t worth it
Most catalogues don’t need one. If your options are independent — a shirt in five colors and four sizes, where every combination is valid and priced the same — that’s a variants problem, and every major ecommerce platform, including Shopify and WooCommerce, already solves it natively and cheaply. Building a configurator for that catalogue adds cost and a maintenance surface with no corresponding benefit.
The honest trigger isn’t catalogue size or revenue. It’s whether you can currently sell your product accurately without someone manually checking that a combination of options makes sense, or manually recalculating a price a system should have handled. If that check is already happening — in a salesperson’s head, a spreadsheet, or a stack of plugins — you have a configurator problem, whether or not you’ve named it that yet.
Frequently asked questions
What is a product configurator?
A tool that lets a customer or salesperson build a product from dependent options, validating each choice against the ones already made and recalculating price as selections change. That’s different from product variants, which is a flat, independent attribute list like size and color.
How is a configurator different from product variants?
Variants are independent: every combination of size and color, for example, is equally valid and priced the same way. A configurator handles dependent options, where choosing one component changes which others are valid and how the price is calculated. If your options don’t constrain each other, you need variants, not a configurator.
Did this client’s configurator come standard with Odoo?
No. It was custom-built specifically for their gate and hardware kits. Odoo’s standard attribute system, like most platforms’, doesn’t ship a cross-attribute compatibility rules engine out of the box. What Odoo’s architecture provided was a single database and a flexible enough data model to build that logic once, natively, rather than stacking several separately-licensed plugins.
Can WooCommerce handle a real product configurator?
Not natively. WooCommerce’s core Variable Product type only handles flat attribute combinations. Nested, rule-validated assemblies with dynamic pricing require stacking separate extensions such as Composite Products, Product Bundles, and Dynamic Pricing, each licensed and maintained independently, and even the most capable of them has documented limits when a component is itself a variable product.
Can Shopify handle a real product configurator?
Not straightforwardly. Shopify caps products at three options regardless of variant count, and its own documentation states that bundles cannot contain other bundles, so a configurator with several independent choices has no native representation. We cover the available workarounds and their tradeoffs in what an Odoo build for Shopify actually involves.
How much does a product configurator cost to build in Odoo?
It isn’t priced separately from the wider implementation. In our experience, Odoo ecommerce implementations run $5,000 to $50,000 (USD), and catalogue complexity, including configurator-style dependency rules, is one of the factors that moves a project toward the top of that range rather than a standalone cost.
Do I need a product configurator?
Only if your options are dependent on each other or price has to be recalculated as selections change. If your options are independent, like size and color that don’t affect each other, standard variants on your existing platform already cover it, and a configurator would add cost without a corresponding benefit.
Ready to talk through your catalogue?
Whether you need a configurator or just a cleaner variant structure depends on how your products actually depend on each other, not on their SKU count. That’s worth fifteen minutes on a real catalogue rather than a generic checklist.
Talk to us about your Odoo ecommerce build →
About the author
Nguyen Tran is the founder of Ministers.io. He has spent five years working on Odoo ERP implementations — five delivered directly and more than twenty advised on — across ecommerce, retail, manufacturing, and maintenance, repair and operations (MRO).
