Three routes exist for putting Web3D on an ecommerce site, and the reason quotes range from eight thousand to three hundred thousand is not dishonesty. It's three different products being priced.
We've run all three in our own projects and inherited the wreckage of migrations from each. This isn't an argument for the best one. It's about which fits you.
The real fork isn't technical
Two questions decide it. Does your product need combinations, and are you willing to pay a platform a cut of every order?
Everything else — rendering quality, feature lists, integration depth — follows from those two.
Plugin: for teams who just want it live
If your products are fixed configurations — one speaker is one shape, one chair is one fabric — and the customer only needs to rotate it, check where the ports are, maybe open the lid, then a plugin is the right answer and it isn't close.
The arithmetic is simple: under two hundred dollars a year, live in half a day, no engineering resource, support included when it breaks. The cleanest example we've seen was an industrial components client with twenty SKUs, each needing an exterior view and the positions of a few connectors. A model-viewer embed plus one custom button, two days, cost effectively zero.
The boundary is just as clear. Plugins show; they don't configure. A customer wanting to change fabric colour can't get real-time rendering out of a plugin — the best it can do is swap to another pre-rendered image. Price updating with the selection is out of reach entirely.
One thing people miss: plugins don't take custody of your model assets. You upload, it lives on someone else's server, and if you switch approach later you upload again. Keep the source files on your own side. In our 3D configurator development contracts the model source files are explicitly assigned to the client, and the same discipline applies to a plugin route.
SaaS: less work, two things to interrogate
Once SKU count climbs and products develop material and accessory combinations, plugins hit their ceiling. SaaS is the sensible middle: real configuration logic, material libraries, a pricing rules engine, no code to write, pay as you use it.
It genuinely saves calendar time. A standard furniture configurator on SaaS takes two to three weeks; building it ourselves runs six to eight. If the goal is validating whether customers will use a configurator at all, SaaS is the fastest way to find out.
The traps are in the pricing structure. The common model is a monthly fee plus a transaction percentage, typically between 1% and 2%, occasionally charged on order value.
That sounds small.
If your average order is twenty thousand and you process a hundred a month, 2% is forty thousand. The monthly fee becomes a rounding error next to that number. The percentage is the real cost, and annualising it is the only honest way to compare against building in-house.
The second trap is data. Which combinations customers pick, where they abandon, which options get clicked most — is that yours or the platform's? Some SaaS products give you aggregates only. No line-level detail, no export, no way to feed your own BI. If that data would inform product development decisions, ask before signing what the export looks like and at what granularity.
There's a more practical one too. SaaS rendering style is theirs, not yours. Material response, lighting, interaction feel — all from one template, and you can adjust colours and copy. If your brand has visual standards, run your own product through their demo first and see whether you can live with it. Finding out after signature is expensive.
Build: only when the configurator has to touch your systems
Custom development ranges widely, from a few tens of thousands for a viewer to a couple hundred thousand for a full configuration and quoting engine. Whether it's worth it comes down to one question: does the 3D output have to feed your business systems?
If the configuration has to generate a quote, write into an ERP, or drive factory scheduling, building is close to the only option. In that case the 3D interface is just the front end. The difficult part is the rules engine and the integrations behind it, and no SaaS vendor will reshape their data model for your ERP.
When we built the motorcycle 3D configurator for Cyclone, Zongshen's premium brand, the bulk of the work wasn't rendering. It was getting the option rules, pricing rules and order structure straight, then wiring them into their systems. SaaS doesn't do that. Plugins certainly don't.
Reverse the picture and building becomes overkill. If the goal is a product page that looks good and lets customers turn the product around, custom work is overspend. We've taken over several projects that retreated from in-house builds to SaaS, and the client's line was always some version of: we couldn't maintain it anymore. Model updates needed a development sprint. A copy change needed an engineer. Annual maintenance exceeded the build cost.
The true cost of building isn't construction. It's the years after.
Matching your situation
Under twenty SKUs, no combinations, validating the concept: plugin. Don't overthink it.
Twenty to two hundred SKUs with material and accessory options, but no system integration: SaaS, with the percentage and data export negotiated before signature.
Quoting, orders, ERP, or configuration complexity beyond what a standard configurator can express: build it, and budget for maintenance as a permanent line item.
There's also a hybrid worth considering. Custom-build the hero products properly and use a plugin for the long tail. We did exactly that on a furniture 3D configurator rollout: six flagship SKUs on a custom configurator, forty-odd others on a light viewer. Cost came in at 1.5x a single-route approach and coverage went up sevenfold.
Whichever route, fix the assets first
All three routes run into the same wall eventually: model assets.
How the models were built determines whether you can switch routes later. We inherited one project migrating from a plugin to a custom build where the models had been made for the plugin — complete internal structure, 4K textures, no separation of parts. Migration meant rebuilding everything. Six figures wasted.
A properly built model has separated parts, layered materials, restrained polygon counts and consistent texture specs. Built that way, the assets survive any route change. It costs very little when done up front. The bill arrives on the day you switch.
Our standards are written up in the 3D configurator workflow guide if you want to audit what you already have.
FAQ
How much do the three routes differ in cost?
Plugins run under two hundred dollars a year. SaaS typically lands between a few hundred and a few thousand dollars monthly depending on SKUs and traffic, plus a transaction percentage. Custom builds start in the tens of thousands and reach the low hundreds of thousands, plus 15 to 20% of build cost annually in maintenance.
Can we start with a plugin and migrate to SaaS or a custom build later?
Yes, provided the models were built to standard. With separated parts and layered textures, the assets carry over. With a quick export, migration cost approaches a rebuild.
What transaction percentage should we expect from SaaS, and how do we judge it?
Most commonly 1 to 2%. Judge it annually: order value times the percentage, compared against a custom build's one-off cost plus yearly maintenance. High order values and volume push the percentage past build cost quickly.
Our product only comes in one configuration. Is a configurator overkill?
Yes. A single-configuration product needs a 3D viewer, not a configurator. The value of configuration sits in combinations and price linkage, and without those needs most of the capability goes unused.