Why 3D product configurators fail in production

A product configurator demo takes about a week. A product configurator that a manufacturer can actually put in front of customers takes considerably longer, and the gap between the two is almost never about rendering. Three.js will happily draw your product. The problems are on either side of that.

1. The CAD geometry is not real-time geometry

This is the one that surprises people most. Your engineering team has a CAD assembly that is accurate to a fraction of a millimetre, contains every fastener, and was built for manufacturing. It is not a 3D model in the sense a browser means. Tessellating it produces millions of triangles describing screw threads nobody will ever see.

Getting from there to something a phone can render is a real piece of work: decimation, retopology, removing internal geometry, baking detail into normal maps, and merging parts that never move independently. It is closer to model-making than to programming, and budgeting a couple of days for it is the most common estimation failure in these projects.

If nobody on the project owns geometry preparation, the project does not have a plan — it has a hope that the CAD export will be fine. It will not be.

2. Options multiply faster than anyone expects

A configurator with six options of four choices each has 4,096 possible configurations. Nobody can review that many, and nobody needs to — but the rules governing which ones are valid still have to live somewhere, and the default place is scattered through the UI as conditional logic.

That works until the third change request. Then a dependency added in one component contradicts an exclusion buried in another, and the configurator starts producing combinations that cannot be manufactured. The failure mode is not a crash — it is a customer ordering something your factory cannot build.

• Model options as data, not as branches in components
• Put dependency and exclusion rules in one place, expressed once
• Make invalid states unreachable rather than validated after selection
• Let non-developers add a finish without a release
• Serialise the configuration to something manufacturing can read directly

The test is simple: if adding a new fabric colour requires a developer, the option system is wrong. That will happen monthly for the life of the product.

3. Performance is budgeted against the wrong device

The configurator is built on a workstation, reviewed on a workstation, and signed off on a workstation. It is then used on a four-year-old mid-range Android phone with eight tabs open, and it does not work.

Mobile GPUs are not simply slower — they are memory-bandwidth constrained in ways desktop hardware is not. Texture memory is the usual culprit. Four 4K PBR textures per material across a dozen materials will exceed what the device can hold, and the browser will either thrash or kill the tab. Neither produces a useful error message.

• Set a triangle, draw-call and texture-memory budget before modelling starts
• Use compressed textures — KTX2 with Basis, not PNG
• Compress geometry with Draco and load progressively
• Instance and merge anything that does not need independent transforms
• Test on real mid-range hardware weekly, not on a throttled desktop

4. Nobody decided what happens after "Add to cart"

A configurator that produces a beautiful render and a price is only half a system. The configuration has to become something the business can act on — a quote, a cart line, a production specification, a BOM. That handoff is frequently discovered late, and it constrains the option model retroactively.

Deciding the output format first is free. Discovering in week six that manufacturing needs part numbers your option model never tracked is not.

The pattern

Every one of these is decided before rendering code is written, and every one of them is invisible in a demo. That is precisely why configurator projects tend to look healthy for the first third and then stall — the demo validates the only part that was never the risk.

If you are scoping one of these, spend the first week on geometry, the option model, the performance budget and the output format. The Three.js part will still take about a week.