What is a 3D product configurator, and who needs one?
A 3D product configurator is an interactive web tool where a buyer picks options for a product, sees an accurate 3D model change in real time, and gets a valid price or a quote request at the end. It sits between a product page and a sales conversation.
The classic buyer in Germany makes or sells something with many variants that people struggle to imagine: an upholstered sofa in 40 fabrics, a fitted kitchen with dozens of fronts and handles, a packaging machine with optional modules, or an e-bike with frame sizes, batteries and colours. Photographing every combination is impossible once variants run into the thousands, and a flat option list hides the thing the buyer cares about, which is what it will look like.
There are also buyers who think they need one and do not. If you sell ten products with two colours each, good photos and a variant selector will convert just as well and cost a fraction. We say so when we see it.
- You probably need one: variants run into hundreds or thousands, and customers ask “what would it look like with…”
- You probably need one: sales engineers spend hours turning vague enquiries into valid specifications
- You probably do not: a handful of colour swaps that a photo gallery can show
- You probably do not: products bought purely on price or technical data sheet
SaaS configurator or a custom three.js build: which should you choose?
Choose SaaS when your options are mostly visual swaps and you want to launch in days. Choose a custom 3D product configurator when rules, prices or integrations are specific to your business and you do not want monthly fees tied to traffic.
SaaS platforms give you a hosted viewer, an admin to upload models and define options, and an embed code. That is a good deal for a furniture retailer who wants fabric swaps on 30 sofas. The limits show up when a kitchen needs worktop depth to depend on cabinet type, when a machine builder’s prices live in SAP or another ERP, or when the configuration has to become a structured quote with part numbers. You end up bending the product to fit the tool.
A custom build uses three.js, a JavaScript 3D library published under the MIT licence, on top of WebGL, which every current browser supports. Your rules and price logic are ordinary code and data you own. The trade-off is a higher upfront cost and responsibility for hosting and updates.
Pick SaaS if
Options are visual, the catalogue is small, you need a demo this month and a subscription is acceptable long term.
Pick custom if
Options depend on each other, prices come from your own systems, and the result must feed a cart, CRM or ERP.
Hybrid
Start on SaaS to test demand, keep your models in glTF, then move to a custom build once the rules outgrow the tool.
How much does a 3D product configurator cost?
With us, a custom 3D product configurator starts at US$900 and usually takes 6–12 weeks. A single product family with visual options sits near the start; several families with dependent rules, live ERP pricing and quote documents sit well above it.
Across the market, quotes for “a configurator” vary enormously because the word covers everything from a colour picker to a full configure-price-quote system. Compare quotes by listing what each one includes, not by the headline number. Ask each bidder the same questions: how many base models, how many option groups, which rules, which outputs, which integrations, who prepares the 3D files.
Running costs are easy to forget. A custom build needs hosting and a CDN for model files, but no per-view licence. SaaS tools charge a subscription that keeps running for as long as you use them. Over three or four years the comparison can flip either way, so model both before deciding.
- Base models: each distinct product family needs its own model set and camera setup
- Option depth: materials are cheap; geometry changes such as lengths and add-on modules cost more
- Rules: every dependency between options needs logic and tests
- Pricing source: static price files are simpler than live ERP or PIM calls
- Exit: cart, PDF quote, CRM record or ERP order each add integration work
For how these numbers sit against other custom software in Germany, see our software cost guide.
How long does it take to build a 3D product configurator?
Plan six to twelve weeks from approved quote to launch for a custom build. The biggest variable is not coding speed but how quickly clean 3D files and a complete option matrix arrive from your side.
The first two weeks go on discovery and assets: agreeing the option matrix, receiving CAD exports or existing models, and producing a first optimised glTF that loads on a phone. By week three you should have a staging link with the real product rotating on screen and the first option groups working. Weeks four to seven add the rules engine, pricing and the exit into your cart or CRM. The final stretch is testing on real devices, tightening performance and training whoever will maintain prices and options.
Projects slip when the option matrix is still being debated in week five, or when the only model available is a 400 MB engineering assembly with every screw included. Settling both early saves more time than anything we can do in code.
Preparing 3D models: from CAD files to web-ready glTF
Your configurator is only as good as its models. For the web, the target format is glTF or its binary form GLB, which the Khronos Group describes as a royalty-free specification for transmitting and loading 3D scenes, and which was published as the international standard ISO/IEC 12113:2022.
Manufacturers usually start from engineering CAD (STEP or native formats from their design software). Those files are accurate but far too heavy: internal parts, fasteners and millions of polygons that nobody sees. Preparation means removing hidden geometry, reducing polygon counts on curved surfaces, splitting the model into parts that options can swap or hide, setting pivot points, and baking materials into textures that look right under browser lighting.
We handle conversion, simplification, compression and part structure for web delivery. We do not sculpt photoreal products from scratch; if you have no CAD or 3D files at all, you will need a 3D artist to create the base models, and we will give them a precise specification so the files arrive ready to wire in.
- Send CAD exports or existing models early, even rough ones
- Agree real-world scale in millimetres so AR placement is correct
- Name parts consistently so rules can address them
- Supply fabric, wood and paint swatches as photos or scans
The rules engine: stopping buyers from building impossible products
A rules engine is the part of a 3D product configurator that decides which options are allowed together. Without one, a customer can configure a 90 cm cabinet in a 60 cm gap, or an e-bike frame that cannot take the chosen battery.
We keep rules as data rather than scattered if-statements in the viewer. Each option group lists its choices, and each rule states a condition and a consequence: hide, disable, force, warn or change price. That structure lets your product team read and review the rules in a spreadsheet, and it lets us write automated tests that try every risky combination before a release.
Typical rule types we see: compatibility (this motor only with that frame), dimensions (width between two limits in 10 mm steps), quantity (at most three add-on modules), and regional availability (a voltage variant only for certain markets). When rules are really complex, such as machine options with engineering constraints, the configurator should call a rules service that your engineers also use, so there is only one source of truth.
Hard rule
Blocks the choice entirely and explains why, for example “Glass door not available with depth under 35 cm”.
Soft rule
Allows the choice but flags it, for example a longer delivery time or a sales review.
Live price calculation in a 3D product configurator
Buyers trust a configurator that shows the price changing as they click. For consumers in Germany, the price shown has to be the total price: § 3 PAngV requires traders offering goods to consumers to state the Gesamtpreis, so VAT and other price components belong in the number on screen.
Price logic usually combines a base price per model with option surcharges, dimension-based prices (per 10 cm of width, per square metre of worktop), quantity breaks and customer-specific lists for trade buyers. Where the prices live decides the architecture. Small catalogues work well with a price file your team edits and we validate on upload. Larger or B2B catalogues should read prices from your ERP or PIM through an API, cached so the configurator stays fast.
Whatever the source, the price calculated in the browser must match what the cart or quote finally charges. We recalculate on the server when the configuration is submitted, and we log mismatches so a stale price list never reaches an invoice.
Trade pricing with approvals is covered in more depth on our B2B portal page.
Connecting a 3D product configurator to Shopware or Shopify
A configurator attached to a shop has one job at the end: put a correctly priced line item in the cart with every chosen option visible to the buyer, the warehouse and the accountant.
On Shopware 6 we build this as a plugin or app that accepts the configuration, validates it on the server, calculates the price and adds a line item with the options stored as payload, so they appear on the order, confirmation email and invoice. Shopware’s own variant system covers simple cases; a 3D product configurator makes sense once combinations are too many to create as variants. On Shopify, a configured product usually becomes a cart line with its options attached as properties and a price handled through the platform’s supported mechanisms for your plan; we check what your plan allows before promising a design.
Either way the configuration also gets a short code or link, so customer service can reopen exactly what was ordered. If your shop itself is due for a rebuild, we can do both at once: shops start at US$750.
Still on Shopware 5? Plan the move to Shopware 6 before building a configurator into an end-of-life shop.
Turning finished configurations into leads and RFQs
For machinery, large kitchens and trade products, the end of a 3D product configurator is rarely a checkout. It is a request for quotation that a salesperson or engineer picks up, and the configurator’s value is that the request arrives complete.
We design this exit carefully. The buyer finishes the configuration, sees a summary with a snapshot image, and submits a short form: name, company, country, contact route, and any notes. Behind the scenes the system creates a record in your CRM with the full option list, part numbers where you have them, a PDF specification and a link back to the live configuration. Sales can reply with a formal offer from their own tools instead of retyping the request.
Keep the form short. Every extra field loses enquiries, and the configuration already tells you more than a long form could. Ask only for what sales needs to reply, collect consent correctly, and let people save a configuration without registering so they can share it with colleagues first.
- PDF spec with snapshot, options, dimensions and indicative price
- CRM record with the configuration as structured fields
- Shareable link that reopens the exact configuration
- Email to the buyer confirming what they asked for
If your CRM cannot hold structured configurations, look at custom CRM development or an AI assistant for lead triage from US$600.
Keeping a 3D product configurator fast on phones
Mobile performance decides whether the configurator gets used at all. Many buyers first open it on a phone, over mobile data, and a black canvas that takes ten seconds to appear loses them.
We budget performance from the start. The first view loads a light version of the model, with detailed parts and high-resolution textures streamed in after the buyer interacts. Geometry is compressed with Draco or meshopt, textures use GPU-friendly compressed formats and sensible resolutions, and materials are kept few so the phone’s graphics chip is not overwhelmed. The page shows a static image of the default product immediately, so something useful is visible while 3D loads.
We test on actual mid-range Android phones and older iPhones, not only on a developer laptop. Battery and heat matter too: a scene that renders continuously drains phones, so the renderer pauses when nothing is moving. Core Web Vitals for the surrounding page are measured separately, because a heavy 3D bundle should never delay the product text and buy button.
Can a 3D product configurator show products in AR?
Yes, and for furniture and bikes it is one of the most convincing features. The configured model can be opened in augmented reality so the buyer sees it at real size in their room or garage.
The web has two main routes. On Android, Google’s Scene Viewer opens glTF/GLB files from a web page, and Google documents launching it through the open-source model-viewer web component with its ar attribute. On iPhone and iPad, Apple’s AR Quick Look displays USDZ files and can be launched from Safari. A configurator therefore needs to export the current configuration in both formats, either generated on the fly or pre-built for the most common combinations.
AR only works if scale is right, which is why we insist on millimetre-accurate models from the start. We also keep expectations honest: AR is a preview, not a measurement tool, and a note next to the button should say so. For kitchens and machines, AR matters less than accurate dimensions and a good PDF.
3D product configurator patterns for furniture, kitchens, machinery and e-bikes
Each sector needs a slightly different configurator, and copying a furniture setup onto a machine usually fails. These are the patterns we plan around.
Furniture and upholstery
Many materials, few geometry changes. Priorities: realistic fabric textures, quick swaps, AR at true scale, fabric sample ordering alongside the cart.
Fitted kitchens
Room dimensions drive everything. Priorities: a grid-based planner, cabinet and appliance rules, worktop pricing by length, and a handover to a kitchen studio for measurement.
Machinery and equipment
Options change function, not just looks. Priorities: engineering rules, part numbers, a PDF specification and an RFQ into the CRM instead of a checkout.
E-bikes and cargo bikes
Frame sizes, drive systems, batteries and accessories. Priorities: compatibility rules, stock-aware delivery times, dealer pickup choices and a clear total price.
Machine builders often pair a configurator with a new product site; see manufacturing website design.
SEO and AI search visibility for configurator pages
Search engines and AI assistants do not see inside a WebGL canvas. A page that is nothing but a 3D product configurator gives them almost nothing to index, so the page around it has to carry the words.
We build configurator pages with real HTML content: a clear product description, key dimensions, materials, lead times, a short FAQ and structured data for the product. Popular configurations can have their own crawlable URLs with a static image, which helps both search results and sharing in messaging apps. The 3D code loads after the main content so page speed stays healthy.
AI search tools such as Google’s AI Overviews quote pages that answer specific questions. A configurator page that plainly states “available widths 160 to 320 cm in 10 cm steps, delivery in six weeks” is far easier to cite than one that hides everything behind clicks. Nobody can guarantee rankings or citations, and we do not promise them. Ongoing SEO starts at US$150/mo if you want help after launch, and many product lines benefit from an SEO-safe relaunch plan when the configurator replaces old pages.
Privacy, accessibility and ownership points for German buyers
A configurator collects choices and often contact details, so German privacy rules apply from the first click. Under § 25 TDDDG, storing or reading information on a visitor’s device needs consent unless it is strictly necessary for the service the user asked for, so we keep analytics and marketing tags off until consent and store saved configurations only when the buyer chooses to.
Enquiry forms collect only what sales needs, the privacy notice explains where data goes, and hosting sits in an EU region with a data processing agreement between you and the host. If you sell to consumers, check with your lawyer whether the accessibility rules in the BFSG apply; a configurator should at least be usable by keyboard, with labelled controls and a text summary of the configuration. Our BFSG requirements page goes further. None of this is legal advice; your own counsel signs off.
Ownership is simple: the code lives in your Git repository, the models and textures in your storage, and the hosting and domain are in your name. At handover you receive the repository, a model preparation guide, the rules and price data files, and instructions for adding a new option without calling us.
Working with a configurator team in India from Germany
India is three and a half hours ahead of German summer time and four and a half hours ahead in winter. A 9:30 call in Stuttgart is early afternoon for us, so your mornings overlap with our working day and feedback you send before lunch is usually picked up the same day.
A 3D project involves more back-and-forth than a normal website, so we set a rhythm early: one short video call a week with a screen share of the staging configurator, WhatsApp for quick questions, and a shared list where your team logs visual issues with screenshots. You never need to install anything; every build is a link that opens on your phone.
The first two weeks look like this. Days one and two: a call to walk through your product, option list and sales process. Within about two working days after that: an itemised quote in USD with SaaS and custom options compared where relevant. After written approval, week one covers asset review and a first optimised model on staging; week two adds camera setup and the first option group. Invoices come from India; you pay in USD or EUR by Wise or wire, tied to milestones you can see. Contracts and any NDA are agreed in writing, and anything not covered falls under our terms. Your accountant advises on booking foreign invoices.
Worked example: a hypothetical cargo-bike workshop in Leipzig
This scenario is invented to show how the pieces fit; it is not a client story.
Say a small workshop in Leipzig builds cargo bikes to order: three frame lengths, two drive systems, four battery sizes, a dozen box and child-seat modules and eight colours. Customers currently email for quotes, and staff spend evenings working out which modules fit which frame. The owners want buyers to configure online, see the bike, get a total price and either pay a deposit or book a test ride.
We would propose a custom 3D product configurator on the existing Shopware shop. The quote would list model preparation from the workshop’s CAD files, a rules table for frame, drive, battery and module compatibility, a price file the owners edit themselves, a Shopware plugin that adds the configured bike to the cart with a deposit, an AR view for the garage, and a “book a test ride” exit that creates a CRM entry instead. Timeline: around nine weeks, with a rotating bike on staging by week three. After launch, two months of free maintenance cover new modules and colours.
3D product configurator checklist and red flags
Run through this list before signing any configurator quote, and again before launch. It catches most of the problems we see in projects that went wrong elsewhere.
- Complete option matrix agreed and signed off by product and sales
- Models at real scale, split into swappable parts, under an agreed file-size budget
- Rules stored as data with automated tests for risky combinations
- Price in the browser recalculated and checked on the server
- Total price shown to consumers, with VAT included
- Tested on a mid-range Android phone over mobile data
- Static fallback image and text summary if WebGL fails
- Consent banner blocks analytics until the visitor agrees
- Code, models and hosting in your accounts, not the developer’s
Red flags in a bid: no questions about your rules, a promise to model every product photorealistically for a tiny budget, a viewer that only works on desktop, pricing hard-coded in JavaScript, or code kept on the supplier’s servers.