I design and build bespoke product configurators for UK ecommerce and sales teams. The work covers the product rules, customer journey, real-time 3D experience and the handoff into a basket, quote, CRM or production process.
A configurator is useful when a product has meaningful choices that are hard to explain with photographs and dropdowns alone. That may include furniture, storage, equipment, vehicles, made-to-order products or any catalogue where size, material, finish and component choices affect one another.
Discuss your product and option structure or use the free 3D product configurator readiness scorecard before commissioning a build.
A configurator built around the buying system
The 3D view is only one part of the job. A production configurator needs three connected layers:
- Product rules — valid options, dependencies, exclusions, dimensions, stock and pricing inputs.
- Customer experience — labelled controls, useful visual feedback, loading and failure states, mobile behaviour and an accessible route through the task.
- Commercial handoff — a correctly identified result passed into Shopify, WooCommerce, a quote, CRM, PIM, ERP or another agreed system.
I work across those layers so the finished experience is not a disconnected visual demo. The scope defines which system owns each field, how invalid combinations are prevented, what the customer can do when 3D is unavailable and how staff trace a configuration after it becomes an enquiry or order.
What I can deliver
- product and option-rule discovery;
- customer journey, wireframes and interaction design;
- a representative working prototype before catalogue-wide production;
- WebGL, Three.js or PlayCanvas implementation where real-time 3D is justified;
- a repeatable pipeline for browser-ready product assets;
- Shopify, WooCommerce, custom ecommerce, quote and API integration;
- performance budgets and realistic device testing;
- keyboard-operable product choices and a non-3D fallback path;
- analytics requirements, consent-state validation and commercial handover;
- release planning, documentation and training for the team that will own it.
The exact stack follows the catalogue, platform and operating model. I do not recommend 3D when a lighter guided form or 2D image system would solve the buying problem more clearly.
Good fit and poor fit
| A configurator is worth exploring when… | A simpler product page may be better when… |
|---|---|
| Customers need to understand how several options work together | Customers only choose one or two familiar variations |
| Invalid combinations create quoting, ordering or production errors | Every combination is valid and easy to explain |
| The visual result materially affects the buying decision | The visual differences are minor or already clear in photography |
| A completed configuration can feed a basket, quote or specification | Staff still have to re-enter the result manually |
| The business can own the product rules and asset workflow | Nobody owns rules, prices and assets after launch |
If the product data or rules are not ready, the first engagement can be a focused discovery and prototype rather than a full build.
First-hand delivery context
My work combines ecommerce delivery with research into real-time product visualisation. The Praxis Digital 3D case study records relevant commercial delivery context and its evidence limits. The Manchester Metropolitan University project covers the research and workflow background behind this area of practice.
These projects show the kind of problem I have worked on; they are not a promise that another catalogue will produce the same commercial result.
How a project moves from brief to launch
1. Discovery and evidence
We identify the buyer, the difficult decision, a representative product, the source systems and the primary commercial action. Unknowns are recorded rather than hidden inside a fixed build estimate.
2. Rules and prototype
I model enough real option logic to expose invalid combinations, asset problems and integration risks. The prototype connects the rule model, interface and intended platform handoff.
3. Production system
The approved approach becomes a maintainable asset pipeline and implementation. Product, price and stock ownership remain explicit so the visual layer does not become a second catalogue.
4. Integration and QA
The final configuration is connected to the agreed basket, quote or business workflow. Testing covers target devices, performance, accessibility, failure states and the non-3D route.
5. Release and ownership
The handover documents deployment, product updates, monitoring, analytics and responsibilities. The owning team should be able to make an agreed routine change without depending on the original build team.
Start with one representative product
Send the current product page, an example product, its option rules and any available CAD or visual assets. I will help identify whether the next useful step is discovery, a narrow prototype or a full delivery scope.
When a product configurator is the right fit
The strongest use cases have a real decision problem behind the visual experience.
Made-to-order and modular products
Furniture, storage systems, equipment, vehicles and other modular products often contain dependencies that are difficult to communicate through a conventional variation selector. A configurator can reveal relevant choices in sequence, prevent invalid combinations and show how the assembled result changes.
Products where material and finish matter
If colour, texture, material or detailing changes the perceived value of a product, a visual configuration can make the choice more concrete. It should support—not replace—accurate photography, samples and clear material descriptions.
Quote-led products
Not every configuration belongs in a basket. For complex or high-value purchases, the right outcome may be a complete, reviewable brief for a salesperson. The customer gets a clearer conversation; the sales team receives better information than a blank contact form would provide.
Internal sales and specification tools
The same rules can support a customer-facing journey and an internal one. A sales team may need extra controls, technical data or approval steps that would be distracting on the public site. Treat those as separate interfaces using a shared source of product truth, rather than forcing one screen to serve everyone.
When not to build one
A configurator adds ongoing operational work. Do not commission it simply because an interactive demo looks impressive.
Pause if:
- the business cannot document its current option and compatibility rules;
- source product data is inconsistent or split across spreadsheets and individual employees;
- there is no repeatable way to prepare new visual assets;
- the expected customer action is still unclear;
- the existing product page has unresolved performance or checkout problems;
- a small set of photographs, diagrams or guided questions would solve the same problem more cheaply.
Sometimes the right first project is not a configurator. It is a rules audit, a better product-data model or a focused prototype that tests one product family.
What product configurator delivery includes
The build is broader than the 3D scene. A realistic delivery scope covers the following workstreams.
Product rules and option logic
Start with real products and real exceptions. Every option needs an owner, a source of truth and defined behaviour when its data is unavailable.
For a commerce implementation, the final state must map cleanly to whatever the platform understands: a variation, SKU, line-item property, bundle, custom quote object or another agreed record. WooCommerce, for example, represents variation details such as SKU, price, stock, dimensions, images and attributes through its product variation model. The WooCommerce product variations documentation shows the data that an integration may need to read or update.
Do not let the 3D layer become a second, hidden catalogue. If prices, availability or product rules are duplicated inside scene code, they will drift.
Use the buyer’s checklist for briefing a 3D product configurator to collect the product, rule, asset and integration evidence needed before a supplier scopes the work.
The 3D asset workflow
Manufacturing CAD is valuable source material, but it is rarely ready to ship directly to a browser. Geometry, materials, textures, naming and variants normally need preparation for real-time use.
glTF is designed for efficient transmission and loading of 3D scenes and models. It can package scene structure, meshes, materials, textures and animation, including as a single binary .glb file. The Khronos glTF specification and guidance make it a sensible delivery format to discuss.
The format is only part of the pipeline. The project still needs agreed budgets, visual references, validation checks and a documented method for adding the next product. A beautiful launch asset is not enough if every later update requires a developer to rebuild the scene by hand.
Real-time rendering and interaction
The visual layer should make the product easier to understand. Camera controls, lighting and animation are secondary to clear option labels, immediate feedback and an obvious route to the next commercial step.
Customers also need a usable fallback. A device may have limited graphics capability, a network request may fail, or the customer may simply prefer conventional images. The page should still explain the product and allow the core buying task to continue.
Ecommerce and business-system integration
The integration contract should state:
- where product, price and availability data comes from;
- how a completed configuration is identified;
- what is sent to the basket, quote, CRM or production system;
- which system owns each field;
- what happens when an API or asset fails;
- how staff can trace a customer-facing configuration back to an order or enquiry.
This is where a polished prototype becomes a commercial system. If the output cannot be priced, fulfilled or understood by the next team, the customer journey is unfinished.
Performance, accessibility and measurement
The configurator has to share a page with navigation, product content, analytics and commerce scripts. Agree the page-level performance budget before deciding how much 3D content to load.
The separate product configurator performance-budget guide covers the payload and interaction constraints worth agreeing before visual production expands.
Google’s current “good” Core Web Vitals thresholds are Largest Contentful Paint at 2.5 seconds or less, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift at 0.1 or less, measured at the 75th percentile. Those are page-level outcomes, not promises that a particular rendering technique will meet them. The methodology is set out in Google’s Core Web Vitals threshold guidance.
Accessibility must cover the complete task, not only the text around the visual. The WCAG 2.2 keyboard requirements state that functionality should be available through a keyboard interface, subject to narrow path-dependent exceptions. In practice, the product choices need labelled, keyboard-operable controls, visible focus and a route that does not depend on manipulating a 3D object.
Measurement should connect configuration behaviour to the commercial journey. Google Analytics documents recommended ecommerce events for viewing items, adding items to a basket, beginning checkout and purchasing. Use that model where it fits, then add a small number of clearly defined configurator events. Google’s ecommerce measurement guide provides the official event structure.
Example: a configurable storage system
Consider a made-to-order storage range with three widths, several internal layouts, two door types and six finishes. Some layouts only work at certain widths, one finish has a longer lead time, and the final result is handled through a quote rather than direct checkout.
A sensible first release would:
- ask for the available space or starting width;
- show only compatible layouts;
- update the visual when doors and finishes change;
- explain lead-time differences at the point of choice;
- create a configuration ID and structured option summary;
- attach that summary to the quote request;
- let the sales team reopen the same configuration.
The first proof is not a claimed conversion uplift. It is operational: valid combinations, accurate option data, acceptable performance on agreed devices, a complete quote record and a handoff the sales team can use.
Commercial performance can then be compared against a defined baseline. Useful measures might include configurator starts, completed configurations, qualified quote requests and later sales outcomes. Any claim about improvement should state the period, sample and comparison method.
What drives cost and delivery time
There is no responsible fixed answer without seeing the product and its systems. These are the factors that change the shape of the work:
| Cost driver | Why it matters |
|---|---|
| Number of base products | Each base model adds rules, assets, QA and maintenance |
| Option dependencies | Conditional logic needs definition, implementation and test coverage |
| Asset condition | Clean, approved real-time assets take less work than inconsistent CAD and reference material |
| Visual accuracy | Material, lighting and dimensional sign-off may require several review cycles |
| Pricing and availability | Live calculations and stock rules create deeper integration work |
| Commerce destination | Add-to-basket, saved design and quote workflows have different data contracts |
| Back-office systems | CRM, ERP, PIM and production handoffs add ownership and failure cases |
| Device coverage | Wider device and browser support increases optimisation and QA |
| Editing requirements | A self-service catalogue workflow requires tooling, permissions and documentation |
Ask suppliers to separate discovery, asset preparation, platform work, repeatable per-product costs and ongoing support. That makes proposals easier to compare and exposes work that might otherwise appear later as a change request.
Common mistakes to avoid
Starting with the rendering library
Three.js, PlayCanvas or another technical choice may matter, but it does not define the commercial outcome. Product rules, data ownership and the buying journey come first.
Treating CAD as a finished web asset
A successful import is not the same as a fast, maintainable asset. Test the full pipeline on the target devices before estimating catalogue-wide production.
Recreating commerce data inside the visual layer
Duplicated prices, SKUs and availability rules drift. Agree one source of truth and a clear integration contract.
Loading everything before the customer can act
The conventional product page still has a job. Use an appropriate loading strategy, useful progress states and a static fallback. Do not make every visitor pay the full technical cost before they have chosen to use the configurator.
Launching without an owner
Product data changes. Browsers change. New devices expose different constraints. Name the people responsible for rules, assets, integrations, analytics and incident response before launch.
Questions to ask a product configurator provider
- How will you model and test invalid product combinations?
- Which system remains the source of truth for price, stock and product data?
- What has to happen to our current CAD or visual assets before they reach the web?
- What performance budget will you work within, and how will it be measured?
- How can a customer complete the core task without using the 3D canvas?
- What appears if a model, API or pricing request fails?
- How will the final configuration reach the basket, quote or production workflow?
- Which analytics events will be implemented and how will they be validated?
- What can our team update without developer support?
- What source code, assets, documentation and training are included in the handover?
For implementation detail, see how to build a 3D product configurator or start a project enquiry with a representative product and its option structure.
Frequently asked questions
What is a product configurator?
A product configurator is an interactive tool that applies product rules while a customer or salesperson chooses options. It may use forms, images or real-time 3D, then pass the valid result into a basket, quote, CRM or production process.
Does a product configurator need to use 3D?
No. If the decision is mainly technical, a guided form or 2D image system may be clearer and lighter. Use 3D when seeing the assembled product materially helps the customer understand or trust their choice.
Can a configurator work with Shopify or WooCommerce?
Yes, provided the configuration can map to the store’s product, pricing and order model. The exact integration depends on whether the result is a standard variation, a bundle, a custom specification or a quote-led product.
How long does a product configurator take to build?
It depends on product complexity, asset readiness, integrations, device coverage and editing requirements. A responsible estimate follows a review of representative products and source systems. Ask for discovery, prototype, catalogue production and ongoing support to be estimated separately.
How do you measure whether a configurator works?
Start with operational measures: valid outputs, completed configurations, usable performance, correct commerce records and successful handoffs. Then compare commercial measures such as qualified enquiries, add-to-basket behaviour or completed sales against a defined baseline. Do not accept an uplift claim that lacks a stated period and comparison method.
What should we prepare before contacting a developer?
Bring a representative product, its option and compatibility rules, current asset files, the intended customer action, relevant platform details and the people who own product and visual accuracy. Unknowns are acceptable; they simply belong in discovery rather than being hidden inside a fixed build estimate.