Custom product configurator development and CPQ.

What a custom product configurator does#

Product options let a buyer choose. A configurator has opinions: it decides what can be chosen, what the result costs and where the finished build goes next. That comes down to four jobs:

1. Only valid builds. Each choice narrows the next, so a buyer can't order, and a rep can't quote, a combination you can't make.
2. A live price. The price follows the build as it changes: every option, size and quantity, at the buyer's own prices.
3. Cart or quote. A build with a final price goes in the cart. One that needs a rep, an approval or a freight quote becomes a quote, with the build attached.
4. Into the ERP. The order reaches the ERP as lines it can make and ship, so nobody re-keys it.

That's configure to order: the product gets made after the order, from exactly what the buyer configured. Most platforms handle part of the first two jobs natively and stop there. The sections below show where each one stops, quoting the vendor's own documentation.

Configure to order, in four jobs

Custom configurator, extension or SaaS app: how to choose#

Do you need custom at all? Often not, and we'll tell you. Buy first: an app or extension that covers your rules is usually cheaper to own than code you have to maintain. Custom product configurator development earns its cost when the rules or the price are the business. Read the table by rows, mark the ones your product can't live without, and stop at the first column that covers all of them.

Buy first: stop at the first route that covers your rules

An app or extension is the right buy when:

• Options are few, and each carries its own fixed or percentage price.
• An admin can set up the dependencies: this option appears only when that one is chosen.
• No rule needs to know what else is in the build or the cart.

Custom wins when:

• Rules span components: this bracket fits these three shelving uprights and nothing else.
• The price is a formula: area times a rate, with minimums, rounding and contract prices.
• Quotes and ERP orders have to carry the full build without re-keying.
• Rules change often, and each change should be reviewed and tested before it ships.

One more check before anything custom. If your ERP is NetSuite and your reps already configure there, NetSuite has its own. As of October 27, 2026, NetSuite's CPQ overview says its CPQ Configurator "lets users configure complex items according to your business logic and add these items to transactions," and its SuiteCommerce Integration launches that configurator from a SuiteCommerce product page. On any other storefront, connecting to it is integration work, so weigh that against keeping the rules in the store. Ask that question before you pay anyone to build a configurator. Us included.

Complex product configurators need rules that stay maintainable#

Why do configurators rot? Rules go in one exception at a time: this color doesn't come in that size, except for one account, except when it ships from the second warehouse. The exceptions end up scattered across templates, admin screens and JavaScript, so every new option means hunting for the rules it touches, and eventually nobody adds options at all.

A complex product configurator stays maintainable when its rules are data, not code:

• One rules file. Options, values and constraints live in JSON: requires, excludes, allowed ranges, defaults and prices. Each constraint is written once.
• One small engine. The same evaluator runs in the browser, to offer only valid choices, and on the server, to re-check every build at add to cart and at quote. A price calculated in the browser is never trusted on its own.
• Tests, like code. Each rule carries cases: builds that must pass, builds that must fail, prices that must match. A change that breaks one doesn't ship.
• Versions. Rule changes go through review, and every order records the rules version that priced it, so last quarter's quote can be honored or re-priced on purpose.

Rules as data: one file, one engine, two checks

Proof: Sprawling hand-maintained configurator rule sets replaced by a small declarative rules engine.

Option, dimensional and quantity-break pricing#

Can the price follow the build? Yes, once you know which pricing models you're running. Most configurators mix four:

• Per-option add-ons. A finish adds a fixed amount or a percentage of the base price.
• Price by dimensions. Width times height times a rate, or length times a rate per foot, with a minimum charge and rounding to the increment you actually cut.
• Quantity breaks. The unit price drops at set quantities, sometimes counted across the whole build rather than one SKU.
• Customer-group and contract prices. The same build costs a trade account less, at the price the ERP holds.

Magento's native custom options cover the first model and stop: because the options "are based on variations of a single SKU, they cannot be used to manage stock or as the basis of price rule conditions." That's why a Magento price calculator usually outgrows them: area pricing, minimums and rounding need an extension that calculates from entered dimensions, or a pricing engine of your own.

Cart or quote: CPQ inside the storefront#

CPQ stands for configure, price, quote. Inside a store it comes down to one decision per build: can the price stand on its own?

• Yes: the cart. Every option, size and quantity has a rule-based price, the checkout can calculate shipping, and nobody has to approve anything. The buyer pays, and the order goes to the ERP.
• No: a quote. The build needs a rep's price, an approval, an engineering check or a freight quote. The buyer submits the configuration, a rep prices it, and the accepted quote becomes the order.

Many stores need both, split by rule: standard builds check out, and anything past a set size or quantity, or with a non-standard option, routes to a quote.

Cart or quote, one build at a time

Adobe Commerce B2B quotes natively. Magento Open Source doesn't: an extension or custom module adds quotes there. As of October 27, 2026, Adobe's Negotiable Quotes page says buyers "submit the quote as a request to negotiate the price from the shopping cart," a sales rep "can create a quote from the Admin on behalf of a specific company buyer," and after acceptance "additional discounts cannot be added to the negotiated quote" and "shipping options are locked on checkout." Company accounts and B2B quotes have to be switched on. Natively, the buyer chooses to ask for a quote. Sending a build to a quote by rule is custom work on either edition. For other platforms, see the quotes and approvals row in our B2B ecommerce capability matrix.

Whatever the platform, the quote carries the whole configuration, so the rep negotiates price, not specs, and the accepted quote reaches the ERP without re-keying.

Configured orders straight into the ERP#

Does someone re-key every custom order? Not if the build arrives in a shape the ERP can make. An ERP product configurator sends it one of two ways, and we pick the one your production already reads:

• A sales-order line that carries the build. The base item, with every choice in its own field. In NetSuite those are transaction line fields, which "appear in the sales order, item fulfillment, item receipt, subscription, and invoice records as columns in the item line."
• A generated item with its bill of materials. The build becomes its own SKU: an assembly item with a bill of materials that "lists the quantities of raw materials, assemblies, sub-components, and parts you need to manufacture a product." Build against NetSuite's Advanced Bill of Materials: NetSuite says bills of materials embedded in an assembly item "will no longer be supported" from 2023.1.

The store reads component stock and lead times back over NetSuite's REST web services and SuiteQL, and works out the ship date from them. One Magento catch on the way out: Adobe's option SKU is "a suffix that is added to the product SKU," so an order line can arrive as a combined SKU the ERP has never seen. We map it, or replace it.

The hand-off: two shapes, one read-back

That's how we build a NetSuite product configurator; other ERPs with an API work the same way. The sync method is on our ERP integration page.

Magento and Hyvä product configurators#

Will it work on your Magento store, Hyvä included? Yes. A Magento product configurator sits on one of three levels, and we use the lowest one that does the job:

1. Native Magento 2 custom options. Right for a few add-ons with fixed or percentage prices, within the limits above: no stock per option, no price-rule conditions, and catalog sales that skip fixed-price options.
2. A mature custom-options extension, extended. An established options extension adds dependent custom options; some add stock per option value or prices from dimensions the buyer enters. When one already covers most of the job, we extend it rather than replace it. Replacing it means rebuilding its setup on every product. Extending keeps that setup and hands what the extension can't express, often rules across components or formula prices with minimums and rounding, to the JSON rules engine above. On Hyvä, check first that a compatibility module exists for it, and who maintains it.
3. A Hyvä-native configurator. When the rules outgrow the extension, we build the configurator for Hyvä itself: Alpine.js and Tailwind CSS on the storefront in place of Luma's RequireJS and jQuery widgets, driven by the JSON rules engine above and re-checked on the server. Hyvä's technical vision names the stack: "we use Tailwind CSS and Alpine.js," having "got rid of the parts we would gladly live without (Knockout, RequireJS, and jQuery)."

Before you buy any storefront extension, a Magento product designer or web-to-print module included, check for a Hyvä version: Hyvä's docs say "modules based on the Magento luma or blank themes require a Compatibility Module to work with Hyvä." Anything we build at the second or third level ships as a Magento module with its own tests, so an upgrade checks a Magento 2 product configurator like the rest of your code. The rest of the platform work is on our Magento development page.

Shopify and custom-stack configurators#

Can Shopify handle a complex configurator? Up to a documented point. As of October 27, 2026, Shopify's help center says "each product can have up to three options" and "you can create up to 2,048 variants for a product," and warns that some themes and apps "might not support more than 100 variants." Past those limits a combination can't be a variant, so a Shopify product configurator leans on two other tools:

• Line-item properties. Shopify's theme docs describe them as a way to "include additional information for a variant that's added to the cart." They carry the build. Repricing the line is Cart Transform's job.
• Cart Transform. A Cart Transform function can expand a line into priced components, merge lines into a bundle, or update a line's price, title and image. Expanding works on any plan through a public app. Updating has a plan gate: "Only development stores or stores on a Shopify Plus plan can use apps with lineUpdate operations." Shopify also "rejects lineExpand, linesMerge, and lineUpdate operations if a selling plan is present," so a configured subscription needs another route.

An app is enough when options are few and each has its own price. When the price is a formula the cart has to enforce, Plus and a custom function earn their place: Shopify's Functions docs say "only stores on a Shopify Plus plan can use custom apps that contain Shopify Function APIs." The rest of that call is on our Shopify development page.

Headless is the middle path: the configurator gets the whole product page, while the platform behind it keeps the catalog, the cart and its limits. A fully custom stack drops those limits too. Our headless commerce page covers when headless pays off.

BigCommerce, briefly: as of October 27, 2026, it allows 600 variants per product and modifiers that change the price by rule, but "inventory cannot be tracked for individual product modifiers." A BigCommerce product configurator that needs stock per option uses variants or custom code.

Variant ceilings per product

Products a configurator fits#

Is your product a configurator product? Probably, if anyone on your team has ever had to say "that combination doesn't exist." The patterns, with familiar examples:

• Made to measure, priced by size. Window blinds, cut-to-size glass and acrylic, rugs, fence panels.
• Built to order from compatible parts. Bicycles, modular shelving, lighting systems.
• Made to order with paid add-ons. Sofas in a choice of fabric and legs; watches with a choice of case, strap and engraving.
• Personalized with the buyer's own text or files. Monogrammed luggage and engraved awards, with a proof to approve before anything is made.

Most real products mix two or three: a made-to-measure item with paid add-ons, at a trade account's price. And one pattern that isn't a configurator job: if every combination is a stocked SKU you already sell, you need variants and good filters.

How a configurator project runs#

What happens first? We start from your orders, not a feature list.

1. Map the rules and the price logic from real orders. Past orders, past quotes, the spreadsheet your reps price from, and the exceptions only one person remembers. Each becomes a written rule.
2. Model them as data, with tests. Options, constraints and prices go into the rules file, and every rule gets cases that must pass and cases that must fail.
3. Replay past orders until the prices match. Every historical build runs through the engine. Each mismatch is either a bug in the rules or a price nobody meant to charge, and you decide which.
4. Launch. The configurator goes live with the server checking every build, and orders and quotes flowing to the ERP.
5. Hand over the rules. Your team gets a rules file it can edit, and the tests that say whether a change is safe.

What does a product configurator cost? The work moves with five drivers: the number of rules, the pricing model, the platform, the ERP connection and the quote flow. We scope from your rules and don't publish prices. Our guide to what an ecommerce website costs covers what the market typically charges, with sources.