Internal product
Build in-house
Your team owns the application architecture, rendering, product logic, infrastructure, quality and roadmap.
3D product configurator sourcing guide
Build, buy or combine? Choose the right configurator path.
Compare an internal build, configurable SaaS and a custom implementation on a maintained platform. Edit the scorecard using your own priorities and evidence.
Open the scorecardThe choice is an ownership decision.
“Build versus buy” is often reduced to license cost against development cost. That comparison misses the larger decision: who owns the product model, 3D pipeline, customer experience, pricing, integrations, quality and change after launch.
The right answer may also be a combination. A maintained configurator platform can supply rendering, rules, administration and operations while a specialist team implements your catalogue, brand, commercial workflow and system boundaries.
Three sourcing models
Configured software
Buy a SaaS platform
A maintained product supplies the core engine and interfaces within its available data, UX and integration model.
Hybrid delivery
Custom platform implementation
A maintained platform is configured and extended around your catalogue, brand, workflows and selected system boundaries.
Editable decision scorecard
Replace default assumptions with your evidence.
Give each criterion an importance from 1 to 5, then rate every sourcing option from 1 to 5. The working score is a conversation aid—not a universal recommendation.
Working score
Build in-house
Working score
Buy a SaaS platform
Working score
Custom platform implementation
CriterionImportanceInternal productConfigured softwareHybrid delivery
Unique experience and technical control
How much does the project depend on behavior a maintained platform cannot expose?
Speed to an accepted customer journey
How important is proving one complete product, price and output before a long platform build?
Available internal product-engineering capacity
Can your team continuously own WebGL, rules, commercial workflows, QA and operations?
Fit for catalogue and product-rule complexity
Can the approach represent dimensions, dependencies, variants and required business outputs?
Integration and data-ownership flexibility
Can stable configuration data move to the required CRM, ERP, ecommerce or production systems?
Long-term maintenance and operational coverage
Who handles browsers, devices, performance, security, monitoring, releases and support?
Total-cost predictability
Can implementation, internal time, infrastructure, usage and catalogue change be forecast together?
Default ratings illustrate common ownership trade-offs and are deliberately editable. Replace them after a proof of concept, reference review, architecture assessment and normalized cost comparison. A high score does not replace security, legal or technical due diligence.
Responsibility map
Ask who owns each layer after the first release.
These are common ownership patterns, not contractual guarantees. Use the table to expose assumptions and replace each cell with a named role or supplier in your plan.
| Layer | Build in-house | Buy SaaS | Custom platform implementation |
|---|---|---|---|
| Product catalogue and rules | Internal product team models and tests everything. | Your team configures within the platform model or requests support. | Catalogue ownership is agreed; platform specialists model complex geometry and rules. |
| 3D content pipeline | Your team creates optimization, naming, materials, variants and publishing tools. | Use the platform importer and supported asset conventions. | Source CAD and references are transformed into the maintained platform pipeline. |
| Customer and sales UX | Fully controlled by your application team. | Configured from supplied templates, components and extension points. | Branded journeys combine platform components with scoped custom experience work. |
| Pricing and quoting | Your team builds calculation, permissions, documents, revisions and approvals. | Use available price and quote functions or connect another system. | Rules and documents are implemented around accepted commercial cases and interfaces. |
| CRM, ERP and production | Your team designs, operates and supports every interface. | Use standard connectors, exports or public APIs where available. | Each required payload, owner, failure path and acceptance case is scoped explicitly. |
| Browser, security and operations | Internal engineering owns releases, quality, hosting, monitoring and incidents. | Vendor owns the core service; your team owns account, data and embedded-site responsibilities. | Platform operations remain maintained while deployment-specific responsibilities are documented. |
Compare total ownership, not only purchase price.
Use the same period, product scope and required outputs for every option. Mark each amount as fixed, estimated, usage-based or excluded.
Open the cost and ROI guide01
Discovery and product modelling
Catalogue structure, rules, price cases, audiences, documents, outputs, ownership and acceptance scenarios.
02
3D preparation
CAD cleanup, component separation, geometry behavior, materials, optimization, cameras and future asset updates.
03
Application and experience
Customer, salesperson, dealer and administrator journeys across desktop, tablet and mobile.
04
Commercial workflow
Price lists, formulas, tax, margin, permissions, quotes, approvals, revisions and customer communication.
05
Integration and data
CRM, ERP, ecommerce, PIM, order, BOM, production, identity, migration and failure handling.
06
Infrastructure and operations
Hosting, CDN, storage, environments, monitoring, backups, security, accessibility and incident response.
07
Internal team time
Decision-making, source-data preparation, reviews, reconciliation, acceptance, training and support ownership.
08
Change after launch
New products, prices, languages, markets, roles, browsers, integrations and renewed regression testing.
Decision gates
Disqualify the wrong ownership model early.
Build in-house only if the capability is strategic
Choose an internal product when the configurator itself is a defensible capability, the required behavior cannot be supplied through maintained platforms, and a permanent product team is funded to own it after launch.
Buy SaaS when the supported model fits
A configurable platform is efficient when the catalogue, user experience, commercial outputs and integrations fit its supported patterns and your differentiation comes from the product rather than the software architecture.
Use a hybrid implementation for complex fit without platform ownership
A custom implementation on a maintained platform can suit teams that need governed product logic, tailored workflows and integrations but do not want to become a 3D software company.
Use one proof-of-concept test pack.
Every option should configure the same representative product. Use approved source data and inspect the saved result, not only the screen. The proof should include:
A normal configuration completed by the intended user
Minimum, maximum and dependent dimension cases
A required option and an invalid combination
One price example reconciled line by line
A quote created, changed and reissued as a revision
The agreed CRM, ERP, order or BOM payload
A catalogue and price change after the project is saved
A mobile journey on a realistic connection
Build-vs-buy FAQ
Questions to settle before procurement.
Should we build or buy a 3D product configurator?+
Build in-house when configurator technology is a strategic product capability, required behavior cannot be supplied through a maintained platform and a permanent engineering team can own the full lifecycle. Buy or configure a platform when speed, maintained infrastructure and standard product patterns matter more than owning the engine. A hybrid custom implementation is another option when the business needs tailored rules, workflows and integrations on a maintained foundation.
What does it take to build a 3D configurator internally?+
An internal build needs more than a WebGL scene. It needs a product and rule model, web-ready 3D asset pipeline, responsive configuration UI, saved state, commercial or ecommerce output, administration, analytics, accessibility, security, testing, hosting, monitoring and a team responsible for product and browser changes after launch.
Is custom software always more flexible than a configurator platform?+
Custom software has a higher theoretical control ceiling, but practical flexibility depends on team capacity, architecture quality and maintenance funding. A maintained platform can be more adaptable for business teams when catalogue, price, language and document changes are supported without another application release.
How should we compare total cost?+
Use one comparison period and include discovery, 3D content, implementation, integration, software, infrastructure, usage, internal team time, quality, support and expected catalogue changes. Separate fixed, estimated and usage-based amounts, then identify which responsibilities remain with your team in every option.
Can we start with SaaS and move to a custom build later?+
Yes, if configuration data, asset ownership, identifiers and export rights are planned from the start. A focused platform implementation can validate the product model and customer journey before a larger investment. The contract and architecture should state how data and assets can be retrieved.
What should a build-vs-buy proof of concept include?+
Use one representative product and test a normal case, boundary, invalid combination, known price, quote revision, downstream handoff and catalogue change. Inspect saved data and operational ownership. A polished 3D demonstration alone does not prove the commercial or maintenance model.
Bring one product. Test Configurix against your scorecard.
We will map your product rules, price example, customer journey and required handoff so you can evaluate platform fit with the same evidence used for every option.
Book a product configurator demo