How to Choose a 3D Product Configurator: A Buyer’s Guide for Manufacturers

The 3D configurator market is crowded, the demos all look impressive, and the differences that will make or break your project are mostly invisible in a demo. This guide is for manufacturers of configurable products evaluating platforms: what to compare, what to ask, and which warning signs predict the stalled projects that research on product configuration keeps documenting.

First, decide what job you are hiring it for

"3D configurator" covers two very different tools that happen to share a viewport:

• A visual sales tool: an interactive 3D viewer with an options panel. It improves engagement and conversion. Shopify's published experiments measured 44% higher add-to-cart with 3D interaction and 5% fewer returns for manufacturer Gunner, and we collect the rest of that evidence in the business case for 3D product configurators. But its output is a pretty picture and an options list.
• A manufacturing system with a 3D front end: a rules engine that enforces buildability, derives pricing, and can resolve every configuration into a bill of materials and production data. Its output is a buildable, priced, manufacturable order.

If your product goes through a factory after the order, you are eventually hiring for the second job, even if you start with the first. Evaluate accordingly: the expensive mistake is buying a sales tool, succeeding with it, and discovering the platform cannot follow the order into production. What following the order into production takes is on our BOM configurator page, and we sort the named vendors by the job each one does in Threekit alternatives for manufacturers.

Seven things to actually compare

1. Depth of the rules engine

Can it express your real constraints, such as dimensional limits, incompatible option pairs, material-dependent hardware, or formula-driven pricing? Bring your two nastiest product rules to every demo and ask to see them modeled live. A rules engine that only does "option A excludes option B" will run out of road on real manufacturing products. Getting those rules out of your engineers' heads is its own discipline, covered in Product Modeling: Turning Tribal Knowledge into Configuration Rules.

2. The 3D asset pipeline (the CAD reality check)

Your engineering CAD files carry manufacturing detail a browser does not need, so they are usually too heavy for real-time web rendering as they are: "we already have CAD, so the 3D is done" is a false assumption that stalls projects. Compression helps a lot. Khronos cites typically 10–25× geometry size reduction from Draco, but someone still has to produce, compress and maintain web-ready models. Ask who produces the optimized web models, what it costs per product variant, and how updates flow when the product changes.

3. Pricing logic, not price lists

Configurable products rarely price from a list; they price from drivers such as area, weight, machine time, and finish class. Check whether pricing is computed from the configuration by rules you control, and whether it already handles B2B needs such as customer-specific pricing, quotes and proposals.

4. BOM and production output

The decisive question for a manufacturer: can each configuration resolve into a bill of materials (parts, quantities, cut dimensions) without a human transcribing it? If yes, ask to see the BOM for a demo configuration. If no, you are buying the visual sales tool from the first section, and the factory keeps its manual bridge.

5. Integration surface

Where do orders, BOMs, and customers go? Into your ERP/MRP, accounting, and e-commerce stack, or into a silo? Ask for the API, webhook, and export story with a concrete scenario from your own operation, not the connector logo wall. If you sell building products, add one more destination: the architect's model, which expects a BIM object of the configured product.

6. Web performance and reach

The configurator is a web page before it is anything else: it must load fast, run on the browsers and mid-range phones your buyers actually use (every modern browser can show 3D; heavy scenes still need careful engineering), and remain indexable and shareable. A configuration a buyer cannot send to a colleague is a quote that dies in committee. Ask for field load times on a mid-range phone; what fast enough means for a 3D configurator is measurable.

7. Who can maintain it

Products change monthly; if every option, price, and rule change routes through the vendor's services team, you have bought a dependency, not a capability. Check the admin experience: can your own staff add options, adjust prices, edit content, and publish safely, without a developer?

Questions to ask every vendor

• Model these two rules from our price book, live, in the demo.
• Show the BOM your system produces for this demo configuration.
• Who builds and optimizes the 3D assets, and what does variant #200 cost?
• What happens to quotes, orders, and BOMs when our product catalog changes? What breaks, and what migrates?
• How do our reps and our customers share and revisit saved configurations?
• What exactly reaches our ERP, in what format, triggered by what?
• Which of your references manufacture configurable products rather than only selling them? Talk to one.

A configurator RFP you can copy

Below is a ten-section RFP outline for a 3D product configurator that your committee can paste into its own document: each section has two or three questions for the vendor and one line on what a good answer looks like. Attach your price book, two of your hardest product rules and one real order before you send it, so every answer has to deal with your product instead of a demo one.

Vendor templates are a fair starting point, and they leave gaps. Tacton’s CPQ RFP template for manufacturers asks about constraint-based configuration, 3D visualization, ERP and CRM integration, SOC 2 and ISO 27001, per-user pricing and two or three case studies. It asks for a typical onboarding timeline rather than a committed date, and it has no question on who owns the rules and data or on what happens when the contract ends; its one export question is about BI tools such as Power BI. Sections 7 to 9 below cover those gaps, and section 10 turns the case-study request into systems you can see running. If you are buying licensed CPQ software, a template like Tacton’s is a good base; add sections 7 to 10 to it.

1. Product and rules scope

Name the product lines in phase one and attach the rules that make them hard to sell.

• Model the two attached rules and show an invalid combination being refused, before we sign.
• Where are rules written and changed after launch (an admin screen, code, a spreadsheet import), and by whom?
• What happens to saved quotes when a rule or a price changes?

A good answer: your own rules running in their system, and a named person on your side who can change them later.

2. 3D assets, performance and mobile

Ask who produces the 3D models, how new variants are priced, and how fast the result loads on the phones your buyers carry.

• Who turns our CAD into web-ready models, and how is each new variant priced?
• What load time do you measure on a mid-range phone for a configurator that is running today? Show us on that phone.
• Which browsers and devices do you support without a plugin or an app?

A good answer: a written answer on who produces new variants and how they are priced, and a field load time measured on a mid-range phone, the way we describe in what fast enough means for a 3D configurator.

3. Pricing logic

Ask how a price is computed from a configuration, because configurable products rarely price from a list.

• Which drivers can a price rule use: dimensions, area, material, machine time, finish class?
• How are customer-specific prices, discounts and approvals handled, and who edits them?
• What does the quote or proposal document carry, and can we change it ourselves?

A good answer: one of your real prices reproduced to the cent from the configuration, by rules your team can edit.

4. Integrations: ERP, CRM and e-commerce

Ask for a field-level map of where one configured order goes, using the real order you attached.

• For the attached order, which fields reach our ERP, CRM and store, in what format, triggered by what?
• Who builds and maintains each connector, and what happens when one of those systems changes its API?
• Can you demonstrate it against a test copy of our ERP or store before go-live?

A good answer: a field map for your order and a named owner for each connector. A page of connector logos answers neither.

5. Dealer and B2B channel

If dealers or trade accounts order from you, ask how they get their own prices and accounts on the same product model.

• Can each dealer see its own net prices, saved configurations and order history, apart from retail buyers?
• Who manages dealer accounts, users and roles, and can a dealer add its own staff?
• Do dealer quotes run on the same rules and prices as the direct channel, or on a copy?

A good answer: one set of rules behind every channel, with prices set per account or tier. Our guide to dealer portals for configurable products covers the rest.

6. Security and hosting

Ask for the vendor’s current security status in plain terms, so your security team can judge it against your own requirements.

• Which audits or certifications do you hold today (SOC 2, ISO 27001, others), and which would we have to commission ourselves?
• In which region is our data stored, and is it encrypted at rest and in transit?
• Whose cloud accounts does it run on, and whose uptime SLA applies?

A good answer: a plain list of what is and is not certified, the data region, and the hosting provider’s SLA named, with nothing you cannot verify.

7. Ownership of code, rules and data

Ask who owns what is built for you, in the contract, because the rules and data are the expensive part of the project.

• Who owns the source code, the product rules, and the configuration and quote data?
• Do we pay a license or per-seat fee to keep using what you built?
• Can the code repository sit in our own GitHub or GitLab from day one?

A good answer: ownership written into the contract. With a SaaS platform the honest answer is a license, which can be the right trade for a simple product as long as section 8 has a clear answer.

8. Exit and handoff

Ask what you receive, in what form and how fast, if the contract ends.

• If we leave, what do we get (code, database export, 3D assets, rules), in what format and within how many days?
• Is there a fee to export our rules, prices and quote history?
• Could our own team or another vendor run and change it without you?

A good answer: a written list of what is handed over, in formats your team can open, and a system that keeps running on accounts you control.

9. Delivery: scope, price and date

Ask when the scope, the price and the delivery date are set, and have the vendor commit to all three in writing before the build starts.

• How long does discovery take, what does it cost, and what does it hand us?
• After discovery, what scope, price and date will you commit to in writing?
• How do we see progress: a working build we can click every week, or status reports?

A good answer: a short discovery that ends in a written spec, a price and a date, then a working build to review every week. Be wary of a price quoted before anyone has seen your rules.

10. References running in production

Ask to see configurators the vendor built that are running today, with real buyers using them.

• Show us two configurators you built that are running today, live or on a call. Which one is closest to our product?
• Can we speak to a client whose product rules are as complex as ours?
• Which results did those clients measure, and how?

A good answer: a configurator you can try yourself, on a live site or a screen share, and a reference call with a manufacturer.

Our own short answers are already published. You own the source code and the data, with no license or per-seat fee, and the repository can live in your GitHub or GitLab. It runs on your cloud accounts from the start, or on ours while we operate it, and we move it to yours whenever you ask. We are not SOC 2 certified: data is encrypted at rest, and if you need the audit, you commission it on the deployed system. Diagnose takes about a week, is included, and ends with a spec, a quote inside our published tiers and a date. SBFS is one senior engineer working with AI, taking five clients at a time. In production: Door Builder, where quote turnaround went from about 2.5 weeks to 4 minutes, plus NOMI and OrthoSolid.

Red flags

• The demo product is simple and the pricing is a flat list. Complexity is where configurators fail; peer-reviewed research on failed configuration projects (Haug, Shafiee & Hvam, Computers in Industry, 2019) points to underestimated product complexity and poor knowledge transfer as leading causes. A vendor who never asks hard questions about your product model is walking you into exactly that.
• "Send us your CAD files and we'll take it from there." See the asset-pipeline reality check above; this sentence usually comes before a change order.
• Scope that ends at the cart when your economics live in quoting accuracy and production flow.
• No answer for who maintains rules after launch. Unmaintained product knowledge is how configurators rot: the rules drift from the factory's reality and trust evaporates.

Cost and timeline expectations

A visual configurator for one product with simple rules takes weeks. An end-to-end platform covering several product lines through BOM and production is a phased project, one product line at a time, and capturing the product rules takes longer than the programming. For our own price ranges, see 3D configurator development cost and timeline. Two structural cost drivers dominate: the number of genuinely distinct product architectures you sell, and the state of your 3D-ready assets. Phase the rollout: one product line, modeled completely through to the BOM, live to real buyers, and only then expand. That sequencing directly addresses the failure causes the research identifies.

When you need an end-to-end platform

Choose a standalone visual configurator when your product is simple, your volumes are low, and your back office happily absorbs orders by email. Choose an end-to-end platform when any of these is true: quoting requires engineering review today; every order becomes a hand-written BOM; option combinations run into thousands; or you sell B2B and buyers expect the rep-free, self-serve experience two-thirds of them now prefer. At that point the configurator, pricing, BOM and production tracking belong in one system instead of four separate products.

Frequently asked questions

How much does a 3D product configurator cost?

It ranges from low-cost SaaS (simple products, visual-only, per-month pricing) to custom builds. Ours are published: from a $4,000 one-time Pilot on your own site to $50,000 and up for the full channel. The main cost drivers are product-rule complexity and 3D asset production. The rendering technology matters less, because it is mature and largely commoditized.

How long does implementation take?

A simple visual configurator: weeks. A rules-complete configurator for one manufacturing product line, through pricing: at SBFS the full channel typically ships in six weeks, and Diagnose sets the date. Extending it to BOM generation: phased per product line. Distrust any timeline quoted before anyone has examined your product rules.

Should we build our own configurator?

Only with a standing engineering team and a genuinely unusual product. The rendering layer is the easy 20%; the rules engine, pricing, BOM derivation, admin tooling, and long-term maintenance are the expensive 80% that platforms amortize across customers.

What should the configurator produce besides an image?

At minimum: a validated, priced configuration a buyer can save, share, and turn into a quote. For a manufacturer: additionally a bill of materials, production-ready specifications, and order data your ERP or production system consumes without re-entry.

What should a 3D configurator RFP include?

Ten sections: product and rules scope; 3D assets, performance and mobile; pricing logic; ERP, CRM and e-commerce integrations; the dealer channel; security and hosting; ownership of code, rules and data; exit and handoff; a scope, price and date committed after discovery; and references running in production. Ownership, exit and a scope, price and date committed after discovery decide what the project costs you after launch; add those three, and ask to see references running, if you start from a vendor’s template. The outline above is free to copy.

Sources

• Shopify: The ROI of AR shopping (Rebecca Minkoff, Gunner)
• Khronos Group: KTX 2.0 and glTF compression launch overview (2021)
• Tacton: The CPQ RFP Template for Modern Manufacturing
• Haug, Shafiee & Hvam: The causes of product configuration project failure (Computers in Industry, 2019)
• Gartner: B2B buyers prefer a rep-free experience (2026 press release)

SBFS is the end-to-end option in this guide: 3D configurators, automatic BOM generation and outputs for production, built as one platform for manufacturers of configurable products. See where we stand on the questions that separate configurator builders.