Letting people build the product before they buy it
There are four ways to do this and they are not tiers of quality — they are different answers to different catalogues. The diagrams below explain how each one actually works, because the difference between them is an asset-production problem rather than a visual one. The right choice depends on how many combinations you sell and how much photography you can afford, not on how impressive it looks in a pitch.
YOU ARE PROBABLY HERE BECAUSE
- customers cannot see what they are buying before they buy it
- a configured order arrives as a paragraph somebody retypes
- your photography cost is growing faster than your range
TYPE 01
WebGL, rendered in real time
3 — 6 monthsno photography at all
No images. The product is a 3D model rendered live in the browser, so options are parameters rather than assets. Change a dimension and the geometry rebuilds. Change a fabric and the material updates. Add an option and you have added a variable, not a photoshoot.
This is the only approach where the combination count genuinely stops mattering. It is also the one that unlocks things the others cannot do at all: continuous dimensions rather than fixed sizes, measurement overlays, animation, and a live price that recalculates as the customer changes the shape.
The cost moves from photography to modelling, and the engineering is real — performance on mid-range phones, colour accuracy against physical samples, and generating a manufacturing spec from what the customer built. This is what I built for Arkansas Lighting, on live catalogue data, and then maintained for nine years.
- SUITS
- Made-to-order, custom dimensions, deep option trees, technical products
- BREAKS
- Where photographic realism sells the product better than accuracy does
TYPE 02
360° frame spinner
6 — 12 weeks36 frames per variant
The product is captured at fixed intervals all the way around — usually thirty-six frames, one every ten degrees. Dragging steps through the sequence and the object appears to rotate. Change the material and the whole set of thirty-six is swapped for another set.
This is the approach Cylindo popularised, and it gives you photographic realism with rotation, which neither of the flat methods can. The cost is in the asset pipeline: every variant multiplies by thirty-six, so preloading, sequencing and image weight become the real engineering problem rather than the interaction itself.
Frames can be photographed on a turntable or rendered from CAD. Rendering is usually cheaper once you pass a few variants, and it is the only sane option if the range changes seasonally.
- SUITS
- Furniture and high-consideration goods where seeing the back matters
- BREAKS
- Deep option trees — the frame count multiplies past what you can produce
TYPE 03
Layered compositing
4 — 8 weeksone photo per part
Each part of the product is a transparent PNG on its own layer. Change the table top and only that layer swaps; the base stays put. The layers are merged into a single image — on the server with GD or ImageMagick, or in the browser on a canvas — and the result is cached so it is only ever built once.
This is where the arithmetic flips in your favour. Four tops and five bases is nine photographs producing twenty combinations, not twenty photographs. With three parts it is the difference between dozens of assets and thousands.
The discipline is in the source files: every layer shot from the same camera position, same lighting, same registration. Get that wrong and no amount of code makes the composite look real.
- SUITS
- Products that decompose into parts — furniture, doors, windows, blinds
- BREAKS
- Where parts change each other's shadows, or where the customer wants to rotate it
TYPE 04
Simple image swap
2 — 4 weeksone photo per combination
The customer picks an option and the whole picture changes. No compositing, no maths — you photograph every variation you sell and the configurator swaps between them.
Its virtue is that it always looks right, because a photographer made every image. Its limit is arithmetic: three finishes across four styles is twelve photographs, and adding a fifth style means five more shoots.
Correct when your combination count is genuinely small, when the product is photographed rather than rendered, or when a first version needs to ship before anyone commits to a bigger build.
- SUITS
- Under about 30 total combinations, photography already exists
- BREAKS
- The moment options multiply — the asset count explodes
What I can do for you
The first one exists because choosing the wrong type is the expensive mistake here, not building the right one.
Which-type scoping
I count your real combinations, look at what photography you already have, and tell you which of the four approaches fits — with the cost of each. You keep the document. Frequently this talks people out of the expensive option.
Configurator build
Image swap, layered compositing, 360 frame spinner or WebGL, built into WooCommerce so the configuration becomes a priced order line rather than a note somebody retypes.
Manufacturing handoff
Turning what the customer built into parts, dimensions and a specification production can work from. Often the harder half, and the part hosted widgets leave you to solve yourself.
Take over an existing configurator
Adding options, fixing pricing rules, or migrating off a hosted tool that cannot do what you now need.
Forty-five minutes, no charge.
I will tell you which of these you need, including when it is the cheapest one.
Choosing between them
The honest version of this table is that most people ask for the first one and need the third.
| Approach | Assets needed | Rotation | Custom sizes | Best when |
|---|---|---|---|---|
| WebGL | One 3D model | Yes | Yes | Made to order, deep option trees |
| Frame spinner | 36 per variant | Yes | No | Seeing all sides drives the sale |
| Layered | One per part | No | No | Product decomposes into parts |
| Image swap | One per combination | No | No | Few options, photography exists |
The part nobody asks about
A configurator that produces a beautiful picture and an order nobody can manufacture is worse than no configurator.
Whatever the customer builds has to become a line on an order, a price the business honours, and a specification the workshop can make. That means valid combinations enforced rather than assumed, pricing that reflects the actual configuration, and output the production side can read.
On the Arkansas Lighting build this was the harder half. The configurator ran on live catalogue data rather than a static option list, so what a customer could choose was constrained by what was genuinely available — and what they chose arrived downstream as something the business could actually fulfil.
Which is the case for building this into WooCommerce rather than bolting on a hosted widget. A third-party configurator gives you the visual and hands you a text field describing what the customer wanted. Integrated properly, the configuration is the order line: priced from your rules, validated against your stock, and passed to your ERP with the parts it needs.
It is also why these projects take longer than the demo suggests. The spinning object is the easy part.
Questions I get asked
Which one do we actually need?
Count your combinations honestly, then count how many photographs you already have. If combinations are in the dozens and your product has separable parts, type two solves it for a fraction of the cost of type four. If you sell made-to-measure, nothing below type four will do. I would rather talk you down a tier than sell you the expensive one.
Can you use our existing product photography?
For type one, usually yes. For layered compositing, only if the shots were taken from an identical camera position with identical lighting, which is rarely true of photography shot for a catalogue. Reshooting the parts is often unavoidable, and it is better to know that in week one.
Why not just buy a hosted configurator?
If you need a visual and nothing else, buy one — I will tell you which. The reason to build is when the configuration must drive price, stock and manufacturing. Hosted tools generally hand your order system a description rather than a specification, and someone in your office ends up retyping it.
Will it work on phones?
Types one and two, trivially. Frame spinners need care over image weight and preloading, since thirty-six images per variant is a real payload on mobile data. WebGL runs well on modern phones but needs a performance budget set early and honoured, not discovered at the end.
What about the manufacturing side?
That is part of the build, not an afterthought. A configuration should arrive in your system as parts, dimensions and a price, in a form production can work from. If it arrives as a paragraph of text, the configurator has moved the data entry rather than removed it.
Tell me how many combinations you sell
That number, plus whether you make to order, usually decides which of the four you need — and I will say so on the call even when the answer is the cheap one.