A product configurator on Magento can be built four ways: native custom options, configurable products with parent and child variants, an advanced options extension, or a fully custom module. The right choice depends on how many combinations you sell, whether options depend on each other, and how each one has to sync to inventory and your ERP.
Most guides stop at “custom options versus configurable products” and leave you there. That comparison matters, but it is not a configurator. A real configurator handles dependent choices, recalculates price as the buyer clicks, keeps the storefront fast while doing it, and hands a clean payload to the cart and your back office. This is a practitioner’s walkthrough of the four build paths, where each one breaks, and how a Hyva storefront changes the performance math.
The four ways to build a configurator on Magento
Every configurator on Magento and Adobe Commerce is some combination of four building blocks. Picking the wrong one early is the most expensive mistake merchants make, because the data model is hard to unwind once you have live orders against it.
- Native custom options. Metadata attached to one simple product: dropdowns, radio buttons, checkboxes, text fields, date pickers, and file uploads. Everything shares one SKU and one inventory record.
- Configurable products. A parent product that groups multiple simple products, each a real variant with its own SKU and stock. Adobe’s own configurable product documentation describes it as a single product with dropdown options where each variation is a separate simple product.
- An advanced product options extension. A third-party module that adds dependent options, image swatches, conditional logic, per-option pricing rules, and stock control on top of native custom options.
- A custom configurator module. Bespoke code, sometimes a canvas-based designer, for products where the combinations are effectively infinite or the pricing logic is unusual.
The decision is not “which is best.” It is “which one matches the shape of what you sell,” and the honest answer is often a mix.
Comparison: which build path fits which product
| Build path | Best for | Separate SKU per combo | Dependent options | Live inventory per option | Typical cost | Hyva effort |
|---|---|---|---|---|---|---|
| Native custom options | A few add-ons on one item (engraving, gift wrap, a size) | No | No | No | Included | Low, renders natively |
| Configurable products | A fixed matrix of variants (size x color) | Yes | Limited | Yes | Included | Low, core Hyva templates |
| Advanced options extension | Dependent choices, swatches, per-option stock | No, by default | Yes | Yes, with the module | License plus setup | Medium, needs a compatibility layer |
| Custom module | Made-to-order, canvas design, complex pricing math | Depends on design | Yes | Custom | Development project | High, built for Hyva from the start |
Read the table by the column that hurts most. If separate SKUs and clean inventory per combination are non-negotiable, you are in configurable-product territory. If choices depend on each other and you need swatches, you need an extension or custom work. If neither of those is true, native custom options may be all you ever need.
Native custom options: what they do and where they stop
Native custom options turn one simple product into what Adobe calls a composite product. You get six input types: field and area text, file upload, dropdown and multiple-select, radio and checkbox, and date and time. Each option can add a fixed or percentage price adjustment on top of the base price. It is genuinely useful, it ships with Magento and Adobe Commerce, and it renders cleanly on Hyva without any compatibility work.
Where it stops is the part merchants care about most:
- No dependence between options. Every choice is shown at once. You cannot say “if the buyer picks aluminum, hide the wood-stain dropdown.”
- One SKU and one stock number. You cannot track inventory for “red, large” separately from “blue, small.” The whole product is in stock or it is not.
- No swatch logic of its own. Native options are form controls, not visual color or material pickers.
- Reporting blindness. Because everything is one SKU, your sales reports cannot tell you which configuration actually sells.
Custom options are the correct answer for engraving, gift messages, a warranty upsell, or a single size choice on an otherwise simple item. They are the wrong answer the moment you need per-combination stock or a choice that changes which other choices appear.
Configurable products: when variants beat options
Configurable products solve the inventory problem that custom options cannot. Each combination is a real simple product with its own SKU, so stock decrements correctly, your ERP sees a discrete item, and merchandising reports are accurate. This is why apparel, footwear, and any catalog with a clean size-by-color matrix belongs here.
The trade-off is combinatorial explosion. Three sizes and four colors is twelve child SKUs. Add a third axis and you are managing dozens of records for one product. Configurable products also have only shallow support for the dependence that a true configurator needs, and every variant has to exist as a real product even if some combinations never sell. On a Hyva storefront the rendering itself stays fast because the theme keeps swatch selection and gallery swaps light, a point covered in depth in rendering complex catalogs on Hyva. The management overhead, not the frontend, is what limits how far configurable products scale.
Dependent and cascading options: the feature merchants actually ask for
When a merchant says “we need a configurator,” they almost always mean dependent options. Pick a frame material and the available finishes change. Pick a mattress size and the compatible bases filter down. Native Magento cannot do this, and configurable products only fake it.
This is where an advanced product options extension earns its license. Modules from vendors such as MageWorx, Amasty, and Mageplaza add conditional logic, image and color swatches, per-option stock control, and dependency rules on top of the native options engine. You define that option B only appears when option A has a certain value, and the storefront enforces it. For made-to-order goods where the combinations are effectively unlimited, a custom module or a canvas-based product designer is the honest path, because no off-the-shelf option tree can model “any text, any position, any font.”
The catch on Hyva is compatibility. Any module that renders frontend HTML was almost certainly written for the legacy Luma theme using Knockout and jQuery, and it will not work on Hyva until it has an Alpine.js and Tailwind template. Hyva maintains a public compatibility-module program for exactly this reason. Before you buy a configurator extension, confirm a Hyva-compatible build exists or budget for one, a check we walk through in our guide to Hyva extension compatibility.
Live pricing and the add-to-cart payload
A configurator that does not update the price as the buyer clicks feels broken. Two things have to work.
First, the storefront has to recalculate the running total on every selection without a page reload. On Hyva this is a small amount of Alpine.js reacting to the option state, which is a much lighter approach than the RequireJS and Knockout machinery Luma used for the same job. Fewer moving parts on the client is the whole reason Hyva interactions stay responsive.
Second, the cart has to receive a clean, validated payload. Every selected option, its price delta, and any uploaded file or custom text must travel with the item into the quote, survive through checkout, and land on the order so your warehouse and ERP can act on it. Getting this wrong is how stores end up shipping the base product and losing the configuration. The payload discipline matters more than the visual polish, because a beautiful configurator that drops half its data at checkout is worse than a plain dropdown that does not.
Keeping a configurator fast on Hyva
A configurator is the heaviest interactive thing on a product page, which makes it the biggest risk to your Core Web Vitals. Interaction to Next Paint is the metric that measures how quickly the page responds to a tap or click, and Google considers 200 milliseconds or less a good score, as documented in the web.dev guide to INP. A configurator that recalculates slowly on every click is precisely what drags INP into the red.
Hyva helps by design. It strips out RequireJS, Knockout, and jQuery and replaces them with inline Alpine.js and native JavaScript, so the code running your option logic is a fraction of what Luma shipped. To keep a configurator fast on a Hyva storefront:
- Keep option state in Alpine, not in round trips. Recalculate price and availability on the client and only call the server when you genuinely need fresh data.
- Respect full page cache. The product page should be cacheable. Anything customer-specific, such as a saved configuration, belongs in Hyva’s private-content layer, not baked into the cached HTML.
- Lazy-load heavy pickers. A large swatch grid or a 3D preview should not block the initial render or the largest contentful paint.
- Debounce recalculation. If the buyer drags a slider, do not fire a pricing calculation on every pixel.
These are the same INP disciplines we cover in reducing Magento INP on Hyva, applied to the most interaction-heavy component on the site.
Inventory, SKUs, and the ERP problem
The build path you choose is really a decision about your back office. Native custom options give the warehouse one SKU and a note; the picker reads the engraving text off the order. Configurable products give the warehouse a discrete SKU per combination, which is clean for stock but multiplies the records your ERP has to hold. A dynamically configured product from an extension or custom module produces a SKU that may not exist as a stocked item at all, which means your integration layer has to translate the configuration into a bill of materials or a made-to-order work order.
This is where a configurator project stops being a frontend task. Bemeir maintains a deep technology partner ecosystem precisely because the configurator, the checkout payload, and the ERP or OMS record have to agree on what was ordered. Decide how a configured item becomes a fulfillable, invoiceable thing before you decide which module renders the dropdowns.
Is Magento plus Hyva worth it versus Shopify for a configurator?
DTC founders ask this constantly, usually after hitting a wall with a configurator on their current platform. The honest answer depends on complexity.
For a handful of variants and light personalization, a hosted platform is often enough, and moving is not worth the disruption. Our Shopify development team builds exactly these when the complexity does not justify Magento. But when you need deep dependent-option trees, per-combination inventory tied to an ERP, custom pricing math, and full control of the storefront’s performance, Magento with Hyva gives you a level of control that hosted configurator apps cannot match, without the tax that made Luma feel slow. Merchants weighing a move should also look at Shopware and BigCommerce, because the right platform is the one that fits your catalog rather than the one with the loudest marketing.
The deciding factor is rarely the configurator UI on its own. It is whether the configured order can flow cleanly into fulfillment at your volume, with your integrations, at the speed your buyers expect.
FAQ
What is the difference between custom options and a product configurator?
Custom options are a native Magento feature: form fields on one SKU that add price adjustments. A product configurator is the broader experience, usually including dependent options, swatches, live pricing, and a validated cart payload. Custom options can be one building block of a configurator, but on their own they lack dependence and per-combination inventory.
Can I build a configurator with dependent options without an extension?
Not with native Magento. Native custom options show every choice at once and cannot make one option depend on another. Dependent or cascading options require an advanced product options extension, or a custom module for the most complex cases. Confirm the extension has a Hyva-compatible build before you commit.
Does a configurator slow down a Hyva storefront?
It can, because it is the most interaction-heavy component on the page and directly affects Interaction to Next Paint. Hyva’s Alpine.js foundation keeps the option logic light, and with client-side recalculation, respect for full page cache, and lazy-loaded pickers, a configurator can stay well inside good Core Web Vitals.
How do configured products sync to my ERP?
That depends on the build path. Configurable products map to discrete SKUs your ERP already understands. Native custom options travel as a note on a single SKU. A dynamically configured item needs your integration layer to translate the selection into a bill of materials or a made-to-order work order, which is an architecture decision to make before the build, not after.
Should a DTC brand move from Shopify to Magento just for a configurator?
Only if the complexity justifies it. Light personalization rarely does. Deep dependent-option trees, per-combination inventory tied to an ERP, and custom pricing math are where Magento with Hyva pulls ahead. The test is whether the configured order can flow into fulfillment at your volume, not how the picker looks on the page.
Where Bemeir fits
As the first US-based Hyva Gold Partner, Bemeir has built configurators across native options, configurable products, extensions, and fully custom modules, and adapted third-party option modules to run on Hyva without losing speed. If you are scoping a configurator and want it to be fast, accurate at the SKU level, and clean all the way through to your ERP, learn more about how we work and bring us the shape of what you sell. We will tell you which of the four paths actually fits.
