A custom 3D product configurator budget needs to cover asset preparation, option rules, the buying interface and the order handoff. A rotatable product model is only one part of that scope. Two suppliers can quote the same product catalogue and still be pricing very different deliverables.
For illustration, 500 hours at an assumed $100 per hour equals $50,000 in development. That is a worksheet example, not a Virtual Verse quote or an observed market average. Before assigning a budget, establish which assets you have and what must happen after a customer makes a selection.
This guide is for teams comparing custom 3D web development proposals. If you first need an explanation of the product itself, our 3D product configurator overview covers how the components fit together.
Price the buying workflow, not just the 3D model
The cost changes when a visual choice becomes a commercial commitment. A product viewer can show an object; a purchasing configurator must also preserve a valid specification and the correct price.
| Scope | Customer outcome | Additional work to estimate |
|---|---|---|
| 3D product viewer | Rotate and inspect a product | Asset optimisation, controls and accessible product information |
| Visual option selector | Preview materials or components | Option interface, materials, part switching and saved state |
| Checkout configurator | Buy the selected configuration | Merchandise mapping, pricing validation, cart and order integration |
| Quote or manufacturing configurator | Request a valid specification for production | Compatibility rules, custom dimensions, quote workflow and downstream data |
Start with the transaction your business needs. A made-to-order item that requires a salesperson's review may need a quote request with a structured specification. Forcing it into immediate checkout can introduce work without solving the actual sales process.
Write one complete example: the initial product, each selection, the final price or quote request, and what the sales or fulfilment team receives. Ask every supplier to estimate that same example.
Asset complexity matters more than raw SKU count
Count reusable product families, distinct shapes and rules as well as SKUs. Many catalogue entries can share one mesh with different materials; a small catalogue can contain several difficult assemblies.
Changing fabric colour is different from changing the number of sofa modules. The first may reuse geometry. The second can require additional geometry, placement rules and validity checks. Khronos describes this distinction through material variant support in glTF assets, where different material choices can share a model.
Ask the supplier to inspect representative source files before fixing the asset budget. CAD or high-resolution marketing models can help, but “we already have the 3D” does not establish that the files are ready for a mobile browser.
The review should identify:
- Which parts must be selectable, hidden or replaced independently.
- Whether materials and textures exist at suitable quality and size.
- Whether dimensions or assemblies change the shape.
- How many genuinely different models must be prepared.
- Who approves visual accuracy against the physical product.
Shopify's product media documentation covers 3D media formats and processing. A platform's upload allowance is not a recommended asset budget for your product page. Agree a performance budget using the target phones and networks.
Separate the configurator from the pricing authority
The browser can display a price, but the buying system must validate the selection and payable amount. Custom line attributes alone do not guarantee either.
Shopify's CartLineInput reference separates the merchandise identifier from additional attributes. Those attributes can carry configuration details. They do not, by themselves, create a valid purchasable variant or change its price.
For each platform, settle where prices and compatibility rules live. If a customer selects an unavailable combination, the application must prevent or clearly resolve it before purchase. If a price changes while a saved configuration exists, define which value is authoritative when the customer returns.
Include the full order path in acceptance testing. The sales team or factory should receive the structured specification, not only a screenshot. Test quantity changes, duplicate cart additions, unavailable components and the return to an earlier saved selection.
This is a major reason to compare deliverables rather than screenshots of competing proposals. Two interfaces can look equally finished while only one sends usable orders to the business.
A worked development-budget example
The following is a fictional estimation worksheet for one product family, supplied source models, a limited set of material and component options, and one commerce integration. It excludes custom dimensions, customer uploads, AR and ERP integration.
| Workstream | Illustrative hours | Cost at an assumed $100/hour |
|---|---|---|
| Discovery, option schema and acceptance criteria | 50 | $5,000 |
| Model preparation and material setup | 120 | $12,000 |
| Browser viewer and configuration controls | 140 | $14,000 |
| Commerce mapping and order handoff | 100 | $10,000 |
| Device testing, accessibility and handover | 90 | $9,000 |
| Development total | 500 | $50,000 |
These are chosen inputs for explaining an estimate, not measured project hours. Replace them with an asset audit and a supplier's proposed work. If the illustrative 120 asset hours became 240, the example would increase by $12,000 at the same assumed rate. That makes the asset assumptions worth resolving early.
A first-year ownership budget then adds licensing, hosting, catalogue updates, support, applicable taxes and an agreed contingency. Ask which changes are included in maintenance and which require a separate quote.
Do not compare a packaged tool's subscription with a custom build's development fee alone. Compare the complete cost of achieving the same workflow over the same period, including setup and exit costs.
Packaged configurator software or a custom build
A packaged tool is worth testing when its rules and integrations fit your catalogue. A custom implementation is worth evaluating when important product or purchasing requirements remain unsupported.
Give the packaged tool your hardest representative product, not only the easiest colour swap. Test an invalid combination and the actual order handoff. Find out whether an option that appears supported in a demo requires a higher plan, a separate integration or supplier services.
For a custom proposal, ask why the proposed technology fits the job. A web-native implementation can sit within an existing product page; an existing Unity application can justify a different approach. The decision should follow the interaction, asset and maintenance requirements, rather than a preference for an engine name.
Use the same comparison questions for both routes: Can your team update options? Who owns the prepared assets? Can configurations be exported? What happens if you change commerce platforms? What remains usable when the subscription or support relationship ends?
Make mobile use and fallback behaviour acceptance criteria
A configurator has to remain usable on the devices your customers bring. Test the option controls and purchasing path as well as the model's appearance.
Agree representative phones, browsers and network conditions before development. Measure loading and interaction on those conditions. Check repeated option changes, orientation changes and returning to the page after another app was open.
Shopify's product media UX guidance covers keyboard access, focus behaviour, descriptions and assistive-technology testing. A customer should be able to understand and select essential options through usable controls, rather than needing to manipulate a canvas alone.
Keep product information and a route to purchase or request help available if the 3D scene fails. Define whether a saved configuration should restore after a reload. These are ordinary buying requirements and deserve a place in the estimate.
Start with one product that represents the difficult work
A useful pilot includes a representative model, a meaningful rule and a complete handoff. It should expose the expensive uncertainty before you prepare the entire catalogue.
For modular furniture, choose a family with a compatibility constraint and a material change. For industrial equipment, choose a configuration that needs a reviewed quote and a structured specification. Record what can be reused and what must be re-authored for the next product family.
Measure completed configurations, valid enquiries or orders, and errors. A model interaction is not a lead. Compare commercial outcomes with the previous buying journey while accounting for changes in traffic and promotions. Do not promise conversion lift merely because a 3D interface is available.
Our Goldhorn project is an internal studio demo of a browser storefront with WhatsApp ordering. It demonstrates immersive presentation work; it is not a published client configurator conversion study. Ask for evidence that matches the specific part of your project a supplier will deliver.
What to include in a request for proposal
Send one representative product family, source models or CAD samples, a full option list and examples of invalid combinations. Explain where prices come from, which commerce or quote system receives the selection, and who maintains the catalogue.
Require the proposal to state asset preparation, rule implementation, integrations, tested devices, handover materials and exclusions. Name the person who signs off visual accuracy and the person who validates the resulting order. Ask for the pilot and catalogue expansion to be priced separately.
Send us your configurator brief with a sample product and the current sales workflow. We can use those inputs to scope the 3D work, the option logic and the handoff your team needs.