Product configurator development

Should you build a configurator or buy a platform?

Buy a platform when the options are visual and independent, such as colour, material and finish on a catalogue product. Build when options interact, when dimensions are continuous rather than a list, or when the configured result has to become a bill of materials and a routing that production will use.

Every page competing for this search sells a build, including this one, so the row worth dwelling on is the first. There is a mature market of configurator products charging a monthly fee, and for a catalogue product with visual options they will do the job for a fraction of what custom product configurator development costs. If that is your situation, buy one. We would rather tell you that now than deliver a build you did not need.

The honest dividing line is whether the interesting work happens before or after the picture. If the hard part is showing a customer what the product looks like in walnut, a platform covers it. If the hard part is knowing that walnut is unavailable above two metres, requires a different edge treatment and adds nine days to the lead time, you are describing a rules engine wired into your own data, and that is a build.

There is a middle path people forget. Buy a platform, prove that customers use it, and build only once you know which eleven of your four hundred options they actually touch. That ordering has saved more money on these projects than any technical decision we have made.

Why is the 3D the easy part?

Because browser rendering is a solved problem and manufacturing rules are not. A developer can put a configurable model on a page in about two weeks using mature libraries. Encoding which combinations are buildable, and turning a chosen configuration into a bill of materials, takes months and needs people who know the product.

Watch any configurator demonstration and count what it proves. It proves the model loads, rotates and changes colour. It does not prove that the configuration can be built, that the price covers the cost, or that the order will arrive in your system as anything other than a list of selected option names.

This matters commercially because the visual is what gets signed off. A configurator that renders beautifully and hands production an order they cannot build has made your business worse: you have added a fast way to take orders that still need an engineer to interpret, and you have promised a customer a price before anyone checked it.

If that is abstract, there is a working demo of exactly this: configure a car, watch the rules refuse combinations that cannot be built, and see the bill of materials, the derived price and the order payload update as you go. The visual is the smallest part of it, which is the point.

So the sequence we use is deliberately backwards from how these projects are usually sold. Prove the handoff first with the ugliest possible interface, then make it look like something. The reverse order feels better for three weeks and costs you the project.

What does a configured order have to become?

Five things: a bill of materials with substitutions resolved, a routing with operations and times for that specific configuration, a price built from both rather than a lookup table, manufacturing files where the shop runs from them, and a stored record of the exact configuration that someone can retrieve in two years.

A configurator that produces only the first column of that table is a quoting tool with pictures. Useful, but it has not removed the engineer from the loop, which was usually the business case.

The third row is where money is lost quietly. When a configurator prices from a table rather than from the configuration it just assembled, unusual combinations get sold at whatever the table said two years ago. The common configurations are fine, because somebody checks those. It is the rare ones, the exact orders a configurator makes easy to place, that are mispriced, and nobody notices until the year end margin conversation.

If your systems already hold the component costs and the operation times, most of this is integration work rather than invention. If they do not, that is worth knowing before the project starts rather than in week six.

Rules driven or CAD driven: which architecture?

Rules driven suits products assembled from a catalogue of components, where the configurator picks parts and checks compatibility. CAD driven suits products that are one parametric model with dimensions, where each variant is generated geometry. The choice is made once and is expensive to reverse, so it belongs in the first conversation.

Rules driven. The product is a set of components that go together in defined ways. A trailer with a chassis length, an axle option, a deck material and a braking package. The configurator holds a model of what fits with what, assembles a bill of materials from the chosen parts, and the geometry is illustrative. Most manufacturing configurators are this.

CAD driven. The product is one parametric model and the variants are dimensions. A conveyor at any length, a window at any size. Here the configurator drives the CAD system, and the useful output is generated geometry: the model, the drawings, sometimes the cutting files. The web interface is the thin part and the licensing and automation around the CAD tool is the real cost.

Products that look similar can need different answers. Cabinetry is usually CAD driven because the panels are generated from dimensions. Industrial equipment is usually rules driven because it is assembled from a catalogue. A boat is often both: a hull from a fixed set of moulds, then an interior assembled from components, which is why those projects are larger than they first appear.

Getting this wrong is the most expensive single mistake available in product configurator development. A rules engine bolted onto a product that needed generated geometry ends with someone drawing every variant by hand, which is the job you were removing.

Which products are worth configuring?

High ticket configurable products, dimension driven products, and anything where a quote currently takes an engineer and a day. Low value commodity products usually are not worth it, because a configurator adds friction to a transaction that already works.

The clearest case is a high value product the buyer wants to see before committing. A boat, a horsebox, a modular building. The order value is large enough that a single sale justifies the build, the buyer genuinely wants to specify it themselves, and the alternative is a sales conversation that takes weeks of back and forth about options.

The least obvious good case is the long quoting cycle. If a quote currently needs an engineer to open a drawing, the saving is engineering hours and faster responses, not marketing polish. That is easy to measure: count the quotes per month and the hours each takes now. If that number is small, the project may not pay back however good the configurator is.

Why do configurator projects fail?

Five failure modes account for most of it: rules that were never documented, a beautiful render with unusable output, pricing from a stale table, modelling every option when customers touch eleven, and nobody owning it after launch.

The first row is the one that decides the timeline. Every manufacturer has rules that live in one engineer's head: the combination that technically fits but warps in service, the finish that cannot go over that substrate, the length beyond which it needs a second support. None of it is written down because nobody needed it written down while a human checked every order.

A configurator removes that human. So the first phase of any serious project is extraction: sitting with the people who know, writing the rules as explicit statements, and finding the disagreements. We have never run one of these sessions without surfacing at least one rule that sales believed and engineering did not.

The last row is the quiet one. A configurator that nobody can update is a liability within two years. Adding a new option should be a form somebody in the business fills in, not a ticket that waits for a developer. If it is a ticket, it will not get raised, and the configurator will slowly stop matching what you sell.

What features does a product configurator need?

Seven, and only four are essential: option selection with live validation, pricing derived from the configured bill of materials, an order output written into your system, and an admin screen your own team can use. Visual rendering, saved configurations and lead capture are valuable but situational.

Feature lists are what every page on this search leads with, which is why they have stopped being useful for choosing anyone. Every provider offers all of these. The differences are in how much rule complexity the system can express and whether the output reaches your ERP, neither of which appears on a feature grid.

On visual feedback specifically. A full 3d product configurator is the right answer when the buyer needs to understand form, scale or how finishes look together: a boat interior, a modular building, a kitchen. It is the wrong place for the budget when the decision is about specification rather than appearance. Plenty of effective configurators for industrial equipment use dimensioned 2D drawings, because that is what the buyer actually reads.

On the relationship to CPQ. Configure, price, quote software overlaps with this heavily, and the boundary is mostly vendor marketing. In practice CPQ tends to describe tools aimed at a sales team, with approval workflows, discount rules and quote documents, while a configurator is more often customer facing. If your constraint is sales approvals and margin control rather than product rules, look at CPQ products before commissioning a build.

The row that decides the two year outcome is the admin screen. It is also the one most often cut when a budget tightens, because it is invisible at launch and only hurts later. A useful test when comparing proposals: ask who adds a new material once the project is finished, and whether that person works for you or for the vendor. The answer tells you what the second year costs.

• Systems integrationGetting the order into your ERP
• Manufacturing softwareShop floor, scheduling and ERP gaps
• Custom software developmentWhen it has to be built
• Application modernizationWhen the system already exists