3D product configurator software: a buyer's checklist

A sofa available in forty fabrics, several sizes and six leg finishes can have hundreds of possible combinations, which makes photographing every version unrealistic. A 3D configurator gives customers a way to see the product in the fabric, size and finish they are considering, rather than relying only on the limited combinations a retailer has been able to photograph.

Choosing the software requires looking beyond how convincing the product appears on screen. The configurator needs to reflect what can actually be made, account for options that affect price or availability, and carry the customer's final specification accurately through the basket, order and fulfilment process.

This checklist covers the practical requirements to consider when evaluating 3D configurator software for a retailer's catalogue.

Two types of 3D configurator

3D configurators broadly fall into two categories: visual customisers and rule-driven configurators, sometimes sold as visual CPQ. The difference comes down to how much the software needs to do with the choices a customer makes.

A visual customiser works well when the choices are relatively straightforward, such as colour, finish, text or a small number of standard add-ons. The focus is on showing each option accurately, keeping the experience quick on mobile and making sure the right selection and price reach the order.

A rule-driven configurator is built for products where one choice affects another. A particular leg may only work with certain frame sizes, changing the fabric could change the price, or a component may only be available from a particular warehouse. The software needs to apply these rules as the product is configured, so customers can only build something that can actually be priced, ordered and made.

A 3D viewer that simply lets a customer rotate or zoom a fixed model is different. It provides a better view of an existing product, rather than letting the customer configure their own version. In practice, the distinction between visual and rule-driven configurators blurs, and more complex catalogues may need elements of both.

Plugin, app or API: how to choose

There are three common ways to add a 3D configurator to an ecommerce site: through a plugin or app, an embed or SDK, or an API or headless setup. The right route depends largely on how much control the retailer needs and how much of the technical work it wants to own.

A plugin or app is usually the simplest route. It installs into an existing ecommerce platform, such as Shopify or BigCommerce, and can get a configurator live relatively quickly. In return for that speed, the retailer works within the provider's setup, including its layouts, features, catalogue limits and release schedule.

An embed or SDK gives the retailer more control over how the configurator fits into the shopping experience, while the vendor continues to run the underlying 3D software. That makes it important to establish where responsibility sits if something goes wrong, particularly with the interface, analytics, performance or accessibility.

An API or headless setup gives the retailer much more control over the experience and allows the same configuration logic to be used across a website, app or other sales channels. It also places more responsibility on the retailer's own technology team, which will need to build the integration, test it and maintain it over time.

The choice should reflect how the configurator will actually be used. A retailer selling configurable products through a single ecommerce platform may find that a plugin covers what it needs, while a business using the same product logic across its website, app and marketplaces may need the control of an API. Being clear about those requirements early can prevent the team from taking on unnecessary technical work or choosing an option that becomes restrictive as the rollout grows.

Buyer’s checklist

Once the type of configurator and its place within the ecommerce setup are decided, the vendor comparison can get more specific. These are the areas worth testing, broadly in the order they tend to come up.

1. Start with the product rules

Giving the configurator a difficult product from the retailer's own catalogue shows what it does with it. If a certain leg only works with two frame sizes, or one material cannot be used above a particular width, the software should prevent the wrong combination from being ordered. How those rules are changed is worth checking too. A catalogue team should be able to add a new fabric or discontinue an option without raising a development request each time.

Test it: Ask the vendor to configure one combination the retailer sells and one that cannot be made.

2. Find out what happens to the 3D assets

Every product shown in 3D has a model, textures and other files behind it, all of which will need updating as the range changes. Find out who creates and maintains those assets, what that work costs and who owns the files. Leaving the platform after three years should not mean discovering that hundreds of product models have to be built again.

File formats are worth checking too. Support for glTF or GLB shows that a model can be delivered in a widely used format; the editable source files are a separate question, and worth confirming directly.

Test it: Ask for a sample model with its textures and metadata, and check what opens outside the platform.

3. Change something that affects the price

Configuration becomes more difficult once a choice affects more than appearance. A larger size might cost more, a particular finish could have a longer lead time, or a fabric may be temporarily unavailable. The customer needs to see those changes as they make their selections, with price, stock and delivery information coming from the right source systems.

Test it: Pick an option that changes both price and availability and watch what happens to each.

4. Follow the configuration into the order

A well-rendered sofa on the product page is of little use if the order arrives downstream as "Sofa, blue". The configuration needs to travel with the customer's order in enough detail for customer service, fulfilment and production teams to know exactly what was bought. A configuration ID, readable specification and visual preview can all help here.

Test it: Place an order, then use the order record alone to work out the exact configuration that was purchased.

5. Map the integrations before signing

The configurator may need information from ecommerce, PIM, DAM, ERP, OMS, CPQ, tax and analytics systems, depending on the retailer's setup. Ask which connections already exist, which ones have to be built and who will own them after launch. API documentation, webhooks, sandbox access, rate limits and versioning are worth reviewing at this stage rather than during implementation.

Test it: Ask the vendor to draw the proposed architecture for the retailer's setup and put an owner against every connection.

6. Test it on the devices customers actually use

A configurator running on a new laptop over office Wi-Fi reveals little about how it will behave for a customer on a mid-range phone and an ordinary mobile connection. Test those conditions directly, including what happens when the browser cannot support the full 3D experience.

Core Web Vitals give a useful baseline: Largest Contentful Paint of 2.5 seconds or less, Interaction to Next Paint of 200 milliseconds or less and Cumulative Layout Shift of 0.1 or less, measured at the 75th percentile.

Test it: Ask to see the devices and connection speeds used for testing, along with real-user performance data from live deployments where the vendor can provide it.

7. Check AR separately

If AR is part of the proposition, good 3D support does not automatically extend to good AR support. Check the devices, browsers and model formats covered, then look at what happens for everyone outside that range. A sensible fallback is worth building in, because AR support will never be universal across a customer base.

Test it: Use one of the retailer's products on the oldest iOS and Android devices the vendor says it supports, then try the experience on an unsupported device.

8. Use the configurator without a mouse

Accessibility is easier to understand through testing than through reading about it. Try choosing every option and moving through the purchase using only a keyboard. Price changes, unavailable options, errors and changes in focus also need to make sense to someone using assistive technology. WCAG 2.2 AA is a useful benchmark to include in the procurement process.

Test it: Ask for the latest accessibility audit and accessibility statement, and establish who fixes issues when they are found.

9. Follow the price through to checkout

For UK retailers, the total presented to the customer has to reflect unavoidable fees, taxes and charges in line with the Digital Markets, Competition and Consumers Act. This becomes particularly relevant when configuration choices change the price or introduce a required service. Where a mandatory charge cannot reasonably be calculated in advance, the information needed to work it out must be given appropriate prominence.

Test it: Build a product where an option or required service changes the final amount and follow the price from configuration through to checkout.

10. Look past the security badges

Ask what customer data the configurator collects, where it is stored, how long it is kept and which subprocessors can access it. Then work through the operational controls, including user permissions, single sign-on, logging, incident response and the process for deleting or exporting data. Certifications are useful evidence, though the operational questions still need direct answers.

Test it: Ask for the current security and privacy documentation and have the relevant teams review it before the contract is agreed.

11. Work out what three years actually costs

Licence fees are only part of the bill. 3D asset creation, implementation, usage or view charges, transaction fees, support and later changes can materially alter the cost of running the platform. There is also an internal cost to consider: someone will have to manage products, rules and assets once the initial implementation team has moved on.

The final question is what happens if the retailer leaves. By that point, the retailer may have invested considerably more in its 3D catalogue than it did at launch, so the ability to take those assets and configuration data elsewhere has real value.

Test it: Ask every shortlisted vendor for the same three-year cost breakdown and a sample of what the retailer would receive on exporting its assets and configurations at the end of the contract.

Build versus buy

Building a configurator makes sense when the way a product can be configured is specific to the business and important enough to justify owning the software behind it. A manufacturer, for example, may have its own modular assembly rules tied closely to how products are made. If the business already has the 3D and web engineering expertise to build and maintain that logic, an in-house platform may be worth considering.

Catalogue size alone is a weaker reason to build. A retailer may have thousands of SKUs, but if most of the choices come down to standard combinations of colour, size or finish, an existing platform can often handle that complexity without the cost of developing one from scratch.

Buying shifts much of that work to the software provider, including browser compatibility, security, administration, analytics and platform maintenance. It is generally the more practical route when the business wants to get to market without creating a permanent internal team to run the underlying technology.

There is also a middle ground. A retailer can use a vendor's 3D runtime and rules engine while building its own interface and integrations around them. This can work well when the underlying configuration requirements are already covered by existing software, but the retailer wants more control over how the experience looks and fits into the rest of the customer experience.

Whichever route is being considered, compare the cost and internal workload over several years. The licence or development cost at launch is only one part of what the configurator will take to run.

Scoring the shortlist and running a pilot

Set a few pass or fail conditions before scoring vendors. A configurator that allows an impossible combination into the basket, loses part of the specification when the order is placed, cannot connect to a required system, or leaves customers without an accessible way to buy, fails at this stage regardless of how it scores elsewhere. High marks for the 3D experience carry little weight unless the order itself can be trusted.

For the platforms that clear those checks, a weighted score helps bring some consistency to the comparison.

Rules, pricing and order integrity carry the most weight because mistakes here follow the order into customer service, fulfilment or production. AR sits lower because, for many retailers, it is an additional feature rather than something the configuration depends on.

The pilot should use a product family that is representative of the wider catalogue, including popular combinations, higher-value options and configurations that should be rejected. A product chosen purely for convenience risks producing a cleaner but less representative pilot.

The team that will eventually run the configurator should also do some of the work themselves: adding an option, changing a rule and updating an existing product without the vendor taking over. This quickly shows how much effort routine catalogue changes require once the platform is live.

What to watch for in a vendor demo?

• Pre-rendered images presented as real-time configuration

• Invalid combinations that still reach the basket

• No stable configuration ID or way to reconstruct the order

• No export path for models, rules or customer configurations

• Mandatory charges that only appear late in checkout

• Performance claims with no device, network or field-data context

• Drag-only controls or no accessibility documentation

• A polished shopper demo with no view of catalogue administration

• A low subscription price that omits asset, traffic, transaction or implementation costs

Conclusion: choose the operating model first

A 3D product configurator should be evaluated from the order backwards. Before comparing visual experiences, retailers must define which configurations are valid, how selections affect price, stock and lead times, and how the final order reaches downstream systems. Testing one representative product family is the quickest way to identify gaps before committing to a catalogue-wide rollout.

Fynd GlamAR supports this pilot-led approach with real-time 3D customisation, 360-degree product interaction and optional 3D model creation. Retailers can test the platform using their own products, configuration rules and commerce systems, then evaluate the asset requirements, integrations, performance and order handoff before scaling.

Ready to see how 3D product configuration could work for a retailer's catalogue?

Plan our GlamAR pilot