English
繁體中文
Two quotes arrive for the same 3D configurator, and one is forty percent cheaper. That gap is almost never a discount. It is a missing workstream, and the only way to find it is to compare 3D configurator proposals by what each one actually includes rather than by the number at the bottom.
The category has a structural quirk that makes this worse than in ordinary software procurement. A demonstration looks complete the moment it loads, because the models in it were made for the demo. The quote can therefore be complete too, and still describe something the buyer will have to fill at their own expense.
The same words, different scopes
Every proposal in this category contains the words "3D models", "integration" and "support". What those words refer to varies more than the prices do.
One proposal counts model production as its own line and says how many products are covered. Another excludes it and mentions, in a footnote or a verbal aside, that the client supplies assets. Both are legitimate offerings. They are not comparable, and the difference between them is usually the largest single cost in the project.
Integration has the same problem. Integration to a shopping cart is a different job from integration to a factory's system of record, and proposals often say "integration with your e-commerce platform" without specifying which end of the chain the data reaches. Support has it too: three months of bug fixes is not the same obligation as ongoing catalogue maintenance in year two.
Where the missing work hides
Asset production is the first hiding place. Platforms price licences and configuration logic correctly and leave modelling out, because modelling is not what they sell; a catalogue of two hundred variants may need more asset work than the entire software layer, and it appears nowhere in the cheap quote. Asking each vendor one direct question, what would it cost to model our catalogue and who would do it, converts the invisible into a line item.
Rules hide in much the same way. A proposal that includes "option selection" but not dependency rules will look cheaper and behave worse, because the difficult half of a configurator is enforcing which combinations are legal, not drawing the options. If a vendor's quote does not use the word rules anywhere, ask whether they intend to build one.
Handoff is the next gap, meaning what leaves the configurator and in what format. A quote that ends at add-to-cart has not paid for the part your operations team will notice. Post-launch obligation hides worst of all: who updates a retired fabric, who re-tests when the platform ships a theme change, who owns the model files if you leave.
What a comparison sheet should require
The most reliable method is to stop comparing totals and align five workstreams, then ask each vendor to price them separately. Asset preparation, interface and rendering, rules and pricing logic, system integration, and ongoing operation. This is close to the four-workstream split one development studio publishes for scoping estimates, with maintenance added because it is the item most often left out of every quote in the category.
Aligned that way, the cheap quote usually reveals itself, and configurator proposal comparison stops being a matter of taste. It may have left assets out, or priced rules as a later phase, or scoped integration to the cart only. None of those is dishonest. All of them change the number you will actually spend by the end of year two.
Attribution matters here as well. Ask what the configurator is expected to do for the business, and insist the answer is measurable, the way the four metrics in 3D configurator ROI are framed. A vendor who cannot connect their scope to a measurable outcome will also struggle to defend their scope when you question the line items.
Reading a low quote correctly
A low quote is sometimes the right answer. Standard options, a handful of products, an existing store, no dependency rules and a model library already in hand: an app or a small custom build genuinely does the job, and paying for enterprise scope would be waste.
The signal that a low quote is not the right answer is usually in the fine print rather than the price. Models excluded. Rules deferred to a phase that has no date. Integration described as "API available". Support measured in weeks with no named owner for the catalogue afterwards. Any one of those can be fine if you have the capability in-house; three of them together are a project you will finish yourself, without being paid for it.
There is also a timing trap worth naming. A proposal that assumes your CAD files are production-ready will move fast, and a proposal that inventories them first will look slower in comparison. The slower one is usually describing the truth; when assets need cleanup, it is the modelling that sets the calendar rather than the software, and the phase breakdown in how long a Shopify 3D configurator takes shows how that plays out on a live build.
Milestones and acceptance, not just totals
Payment structure tells you what a vendor believes about their own risk. A schedule that front-loads most of the fee into kickoff asks you to carry the risk; one tied to milestones, model accepted, rules demo accepted, integration test passed, shares it.
Write the acceptance tests before you compare. What counts as a finished model, measured how. What configuration must the rules demo reject, and can you name it from your own catalogue. What does the integration test prove, a cart line or an order in a system your operations team uses. Three or four observable tests will separate proposals faster than another hour of sales conversation, and they cost nothing to write.
Ask as well what happens at the exit. You should own the glTF files and the rules documentation outright, in a format the next studio can read. A proposal that keeps the asset library on the vendor's platform, in the vendor's format, has priced a subscription without calling it one.
What to put in front of both vendors
The brief is what does the aligning work, so the identical brief goes to everyone. Product list with variant counts, rule examples including a refused combination, the systems the configuration must reach, the target devices, and the acceptance test you intend to run. A vendor who answers that brief line by line is giving you something comparable; a vendor who replies with a capability brochure is not, no matter how good the brochure is.
We quote this way because it is the only way we have found to be honestly comparable with a platform licence, and the same five workstreams appear in how we scope a build, for example in custom furniture 3D projects where the module list and rule set come before any rendering.
If you have two quotes in hand and want a third opinion on what each one leaves out, send them over. Comparing 3D configurator development quotes line by line takes an hour and routinely saves a quarter.
FAQ
Q: Why is one 3D configurator quote so much cheaper than another?
Usually because it covers a smaller scope. The common exclusions are model production, dependency rules and integration beyond the shopping cart. Cheaper is not automatically worse, but the difference needs to be identified before signing rather than during month two.
Q: Should I ask vendors to itemise by workstream?
Yes, and require it in writing. Asset preparation, interface and rendering, rules and pricing, integration and ongoing operation priced separately makes proposals comparable. A vendor who will not break down a quote is not giving you something you can compare.
Q: How do I know if the scope includes the rules layer?
Ask them to walk through one refused combination from your own catalogue and explain where that refusal lives. If the answer is a person, a note or a later phase, the rules layer is not in the build.
