How a Product Configurator Is Built

A configurator looks like a website with a 3D model on it, and that appearance hides almost everything about how one is actually produced. The model is the visible fraction of a system whose difficult parts are a component library, a rules layer and a material system that has to stay consistent across thousands of combinations.

This guide describes how one gets built, in the order the work has to happen, and what each stage determines. It is written for the person paying rather than the person implementing, because the decisions that matter most are commissioning decisions.

Stage one: describe the product as a system, not as a catalogue

Before any modelling begins, somebody has to write down what the product actually is in structural terms, and this document almost never exists in a form anybody can build from.

What are the components. Which ones are interchangeable. Which combinations are valid and which are physically impossible. What varies at the surface and what varies in geometry. Where does a choice cascade, meaning selecting one thing eliminates or requires another.

That description is the specification for everything downstream. Without it, a studio models what it sees in a brochure, which is a set of finished products rather than a set of parts that combine, and the resulting assets cannot be recombined.

Producing this document is frequently the first real work of the project and it usually falls to somebody in product or engineering rather than to marketing, which is why it stalls.

Stage two: decide what the customer is actually choosing

There is a difference between the options a product has and the options a customer should be offered, and configurators routinely present the first.

A manufacturer with two hundred fabrics knows all two hundred exist. A customer offered two hundred fabrics chooses none of them, abandons the session, and the configurator has reduced conversion rather than improved it.

The useful version presents the choices that matter, in the order customers make them, with the rest available to anybody who goes looking. That is an editorial decision about the product line and it should be made before anything is built.

It also has a direct production consequence, because every option presented is an asset that has to exist, be correct and be maintained.

Stage three: build the component library

This is the largest single piece of work and it is not the same as modelling the products.

Each component is modelled once, at correct dimensions, with correct connection geometry so it joins to everything it can join to. A panel that meets a worksurface has to meet it exactly, in every combination, at every height, or the assembly will show a gap or an overlap that a customer will see.

The library is built for recombination rather than for appearance, which is a different discipline from producing a hero image. A component that looks perfect alone and misaligns in one of forty combinations is a defect, and finding it requires testing combinations rather than reviewing renders.

The payoff is that once the library exists and combines correctly, new products assembled from existing parts are close to free, which is how the product line was designed in the first place.

Stage four: the material system

Materials in a configurator are not applied per product, they are authored once and used everywhere, and getting that wrong produces the most visible failure in the category.

The same oak has to read as the same oak on a door, on a side panel and on a large surface. If each was authored separately, they will differ subtly in tone and grain scale, and a customer configuring a matching set will see three different oaks.

That means materials are a shared system with its own rules: correct scale, correct orientation on curved and flat surfaces, and behaviour that holds under whatever lighting the configurator uses.

It also means adding a new finish later is a single authored material propagated across the library, rather than a per product task, provided the system was built that way at the start.

Stage five: the rules layer

The rules encode what can actually be manufactured, and they are where a configurator earns its cost for any product with real constraints.

Rules come in a few recurring shapes. Some options exclude others. Some require others. Some are only available within a range of another dimension. Some change the price and some do not.

Encoding them is not a visual task and it is frequently underestimated because it looks like data entry. In practice it is the stage where the product knowledge that lives in experienced people has to be made explicit, and that knowledge is usually undocumented.

The characteristic discovery here is that nobody in the business can state all the rules with confidence, and assembling them exposes disagreements that were previously invisible.

Stage six: optimisation for the browser

Everything built so far has to run on a phone, in a browser, over an ordinary connection, and the constraints there are far tighter than most product teams expect.

A component library authored at production quality is too heavy to load. It has to be rebuilt lighter while preserving the silhouette, the proportion and the material read, and that rebuild is a real stage rather than an export setting.

Loading behaviour matters commercially here for the same reason it does in any browser experience: a customer who arrived from an advertisement has no commitment and abandons during a wait.

The workable target is that something recognisable appears quickly and refines, rather than nothing appearing until everything is ready.

Stage seven: the commerce connection

A configured object has to become something the business can act on, and this handoff is where the commercial value of the whole project usually sits.

What leaves the configurator is a structured description: which components, which materials, which dimensions, at what price. That has to reach a quoting system, an order system or at minimum a person, in a form they can use without re typing it.

Re typing is where errors enter, and eliminating that re typing is frequently the actual business case rather than the customer experience improvement that gets presented in the pitch.

It is also an integration project with its own timeline, and treating it as a final step rather than a parallel workstream is a common cause of a configurator that works and is not connected to anything.

Stage eight: testing combinations rather than reviewing images

Quality assurance for a configurator is unlike any other visualization deliverable, because the thing being checked is not an image, it is a space of possibilities.

Reviewing twenty renders proves nothing about the other four thousand combinations. What has to be tested is that components meet correctly across the range, that materials read consistently, that rules block what they should block, and that nothing produces a broken assembly.

Some of that can be automated by generating combinations systematically. Some of it requires a person who knows the product looking at the combinations most likely to be wrong.

Budgeting for this stage is unusual and skipping it is how a configurator ships with defects that customers find rather than reviewers.

The stage that decides whether it survives contact with customers

There is a step between building the system and launching it that almost no configurator project schedules, and it is the one that determines whether the thing gets used.

Somebody who has never seen the product has to configure something, unassisted, while somebody watches without helping. Not a colleague, not a dealer, not anybody who knows the catalogue. A person with the same knowledge a customer arrives with, which is none.

What that session exposes is consistent across projects: the first choice presented is not the choice the customer wanted to make first, the option names are internal vocabulary rather than customer vocabulary, and the point where they get stuck is a rule that blocks them without explaining why.

All three are cheap to fix before launch and expensive afterwards, because by then the configurator has an abandonment rate and nobody knows which of a dozen possible causes produced it.

Naming things the way customers name them

This sounds trivial and it is one of the most reliable causes of abandonment in configurators built by manufacturers.

Internal product vocabulary is precise, established and completely opaque to an outsider. A finish code, a series name, a component designation and a family abbreviation are all meaningful to the business and meaningless to somebody deciding whether to buy.

The customer facing layer has to translate, which means somebody has to decide what each thing is called in plain language, and that decision belongs to whoever knows how customers talk rather than to whoever maintains the part numbering.

It also means the configurator carries two vocabularies at once: what the customer sees and what the order system receives, mapped to each other. Building that mapping late is substantially harder than building it in.

The order matters more than in other projects

Several of these stages appear reorderable and are not, and getting the sequence wrong causes rework rather than delay.

The product description comes first because the library is built from it. The library comes before the materials because materials are applied to it. The rules can be developed in parallel with the library but cannot be tested until it exists. Optimisation comes after the library is correct, because optimising something that will change is wasted work.

The commerce connection is the one genuinely parallel workstream and it should start early, because it depends on another system whose owners have their own priorities.

Where the surprises come from

The rules that nobody could state. This is the most common and the most disruptive, because it stops the project while the business decides what its own product actually does.

Engineering data that does not match the marketing catalogue, which surfaces the moment somebody models from the real dimensions.

Materials that have never existed digitally, which is normal for a manufacturer whose finishes were only ever physical samples.

And components that were designed to combine in principle and do not combine cleanly in geometry, which is a real manufacturing tolerance question that a 3D model exposes with uncomfortable precision.

What the client has to supply, realistically

The structural product description, which is the item most likely to be missing and the one nobody else can write.

Dimensions from engineering rather than from marketing, because a customer will act on what the configurator shows.

Physical samples or accurate references for every material, since a finish cannot be authored from a photograph on a datasheet.

A named person who can settle a rules question in a day, because those questions arrive constantly and each one blocks work.

And a decision about what happens when the catalogue changes, which is an operating commitment rather than a project input.

How long it actually takes

The library dominates the timeline and it scales with component count and combination complexity rather than with product count, which is why estimates built from a catalogue list are usually wrong.

The rules layer scales with how undocumented the product knowledge is, which nobody can estimate until they start.

The integration scales with the other system rather than with this one, and is the most common source of a delay that neither party controls.

The realistic approach is to launch with a subset that is complete and correct rather than a full catalogue that is partially wrong, because a configurator with gaps is discovered by customers.

What good looks like when it is finished

A customer configures something and it is manufacturable, priced correctly, and shown at accurate dimensions.

The materials look like the same materials across every product they appear on.

The configured output reaches whatever quotes or books it without anybody re typing anything.

Adding a new finish takes one authored material rather than a project.

And somebody inside the business owns keeping it true, because the catalogue will change and a configurator that drifts becomes a liability rather than an asset.

Frequently asked questions

What is the largest piece of work in a configurator build?

The component library. Each part is modelled at correct dimensions with correct connection geometry so it joins to everything it can join to. It is built for recombination rather than appearance, which is a different discipline from producing a hero image.

Why do materials need their own system?

Because the same finish must read identically wherever it appears. Authored separately per product, the same oak differs subtly in tone and grain scale, and a customer configuring a matching set sees three different oaks. A shared system also makes adding a finish a single task.

What usually stalls a configurator project?

The rules nobody can state. Product knowledge lives in experienced people and is undocumented, so assembling it exposes disagreements that were previously invisible and stops the project while the business decides what its own product does.

How is a configurator tested?

By testing combinations rather than reviewing images. Twenty renders prove nothing about four thousand combinations. Components must meet correctly across the range, materials must read consistently, and rules must block what they should block.

Should we launch with the full catalogue?

No. Launch with a subset that is complete and correct rather than a full catalogue that is partially wrong, because gaps are discovered by customers rather than reviewers and a configurator that misinforms is worse than one that is smaller.