Choose how to build a 3D configurator by deciding what your business must own, what a platform can responsibly provide and what your team can operate after launch. A custom build is sensible when the experience or product logic is a genuine differentiator and no platform fits the hard requirements. A platform is sensible when its rule, visual, integration and governance model fits with tolerable compromises. A hybrid keeps selected differentiating layers custom while using managed capabilities elsewhere.
That answer is less tidy than “build for flexibility, buy for speed,” but it is more useful. A platform still needs product data, 3D assets, integration, testing and ownership. A custom codebase still depends on browsers, libraries, infrastructure and external services. Neither path removes operating work; it changes where that work and risk sit.
This article compares the three operating models. The 3D product configurator guide defines the wider system of rules, visuals and outputs. The architecture and phases guide covers implementation after the path is chosen.
Define custom, platform and hybrid before comparing them
Teams often call any branded interface “custom” and any licensed component “platform.” Those labels hide the contract that matters.
- A custom path gives your team or delivery partner responsibility for the application layers selected for the build: product-state model, rule behavior, experience, 3D runtime integration, commerce handoff and operations. It does not mean writing a renderer, commerce engine or every library from scratch.
- A platform path configures and integrates a vendor product whose supported runtime, authoring, rule or publishing capabilities supply most of the configurator. Your contract, data model and selected plan determine what you can extend or export.
- A hybrid path keeps named layers under your control and adopts managed components for the rest. For example, the buyer flow and product-rule service may be custom while asset delivery and rendering use a managed runtime. The seam must be explicit; “hybrid” is not permission to postpone ownership decisions.
AWS’s architecture guidance describes vendor lock-in as a loss of control with switching costs in money, effort and time, and repeats the heuristic to build software that differentiates the business and buy the rest.[1] Treat that as a question, not a verdict: which parts of this configurator would a buyer notice, which parts encode protected product knowledge, and which parts are common infrastructure?
| Path | Strong starting signal | Main risk to prove | Ownership test |
|---|---|---|---|
| Custom | Distinctive rules, interaction or outputs cannot fit a credible platform boundary | The team can deliver and operate the full selected scope | Name the product, engineering, 3D, integration and support owners |
| Platform | Supported platform behavior fits the product with acceptable adaptation | Vendor limits, commercial terms and extension seams remain acceptable | Confirm who owns configuration data, assets, changes, incidents and exports |
| Hybrid | Differentiating layers can be separated from suitable managed capabilities | The boundary will remain testable through upgrades and failures | Document each interface, version, fallback and replacement route |
Do not choose 3D before confirming that 3D is needed. Use the 2D versus 3D configurator worksheet for that earlier catalog decision. This framework assumes an interactive 3D path has survived it.
Apply hard gates before weighted scoring
A weighted score can hide a fatal miss. Check these gates first and record the evidence, not an optimistic yes.
Product-rule gate
Can the path represent defaults, dependencies, exclusions, calculated values and invalid states without duplicating business truth in several layers? Test the hardest representative rule, including how an editor changes it and how the buyer recovers from an invalid choice.
Authoritative-data and transaction gate
Can the configurator use stable product and option identifiers, receive authoritative price or availability where required, and preserve an accepted configuration into cart, quote, order or production handoff? A screen summary is not enough. Retain the exact downstream payload and rejection behavior.
Integration gate
Can every required system be reached through a supported, versioned contract with documented authentication, limits, failures and test environments? OpenAPI defines a standard, language-agnostic description for HTTP APIs and formally describes an API surface and its semantics.[3] An API description will not make a weak integration reliable, but it gives both sides something inspectable to test and replace.
Experience and accessibility gate
Can the path support the required buyer or sales workflow across the agreed input modes and devices? WCAG 2.2 describes technology-independent, testable success criteria and notes that they can be used in purchasing, design specifications and contractual agreements.[5] Put the intended conformance target and evidence in the brief; do not accept “accessible component library” as proof of an accessible end-to-end configurator.
Security and governance gate
Can the team control privileged changes, protect saved configurations and customer data, review releases and recover from a bad rule or asset? For acquired software, NIST’s vendor-risk guidance recommends examining supplier development and security practices and carrying requirements for delivery, operational support and maintenance into supplier agreements.[2] The guidance targets federal acquisition, but the questions are useful in commercial diligence too.
Exit gate
Can you retrieve the product data, rule definitions, approved 3D masters or delivery assets, saved-state references and integration documentation needed to continue operating or migrate? A standard asset format helps only with the layer it covers. Khronos defines glTF as an API-neutral runtime asset delivery format intended for interoperable 3D transmission and loading.[4] A GLB export does not automatically carry your commercial rules, authoring history, pricing contract or saved configurations.
If a path fails a non-negotiable gate, either reject it or document the approved exception and mitigation before scoring.
Use the weighted build-buy-hybrid scorecard
The scorecard below is an original Double Edged decision framework. Change a weight only before scoring and record why. Rate each path from 1 to 5: 1 means unacceptable, 2 means a major compromise, 3 means workable with named conditions, 4 means a strong fit, and 5 means an evidence-backed fit. For each cell, calculate weight × rating ÷ 5; the seven default weights total 100.
| Criterion | Weight | Evidence for a high custom score | Evidence for a high platform score | Evidence for a high hybrid score |
|---|---|---|---|---|
| Buyer-experience differentiation | 20 | The distinctive flow can be owned, tested and changed without fighting a generic interaction model | Supported controls and extension points fit the intended flow without misleading workarounds | Custom experience can consume managed capabilities through a stable boundary |
| Product rules and data fit | 20 | The team can model, govern and test the required logic against authoritative identifiers | The platform represents hard rules and publishing governance without lossy duplication | Authoritative rules remain owned while the platform consumes resolved state or approved mappings |
| Integration fit | 15 | Required commerce and enterprise contracts are feasible and the team can operate them | Supported APIs, webhooks or connectors meet the exact transaction and failure requirements | Custom adapters isolate proprietary integrations from replaceable managed components |
| 3D and content pipeline | 10 | Asset production, optimization, mapping, review and delivery have named owners and tooling | The platform accepts the real source condition and supports review, variants and updates | Owned masters and mappings can feed a managed runtime without blocking later reuse |
| Delivery evidence | 10 | A representative vertical slice proves the risky custom seams | A configured proof proves limits, quality and integration behavior on the intended plan | A proof exercises the custom-managed boundary, including outage and upgrade behavior |
| Operating ownership | 15 | Budget and accountable people exist for releases, monitoring, support and browser change | Supplier service plus internal product, content and integration owners cover the full operation | Each incident and change type has one owner across the shared boundary |
| Exit and portability | 10 | Source, contracts, data and assets can be transferred to a future team | Export rights, formats, assistance and transition terms are tested rather than assumed | Replaceable components sit behind documented interfaces and owned canonical data |
Score evidence, not possibility
Create a short evidence card for every rating. State the requirement in testable language, identify the inspected artifact or observed behavior, record the limitation, name the owner and specify the next test. “API available” is too vague. “The selected plan accepts a versioned configuration ID, returns the documented rejection state and can be exercised in a non-production environment” is a claim the team can check.
Use the same standard for all three paths. A platform does not earn a high score from a sales presentation, an uncontracted roadmap item or a capability available only on a different plan. A custom path does not earn one from theoretical freedom; show the skill, budget, architecture decision and working seam required to deliver it. A hybrid does not inherit the best score from each side. Prove that the boundary preserves the benefit when a managed service is slow, unavailable or upgraded.
Separate missing evidence from a poor fit. Missing evidence calls for a proof, document or commercial clarification. A poor fit means the path fails the stated requirement even when it works as designed. This distinction prevents a team from treating every unanswered question as a future implementation task.
Have product, engineering, commerce and operations owners rate independently before a reconciliation meeting. A large disagreement is useful. It usually points to a hidden assumption about what the buyer needs, where product truth lives or who will maintain the result. Preserve the original ratings and the reason for any change instead of replacing them with a polished consensus number.
Finally, list disqualifying exceptions beside the score. A path with the highest total may still be unacceptable because a required rule cannot be represented, an authoritative transaction cannot be preserved, a contractual term is unresolved or nobody owns operation. The exception should name the decision maker and the evidence required to close it.
A total is a comparison aid, not an automatic approval. Keep the ratings, evidence links, exceptions and dissent beside it. Run a sensitivity check on the top two choices: if a small reasonable weight change reverses the result, the decision is close and should turn on a proof or contract term rather than another workshop.
The current Custom Configurator Scope and Budget Estimator maps visitor-supplied rules, assets, visualization, integrations, pricing, outputs and operating ownership into a complexity profile and recommended next step; the profile does not require email.[6]
Test the leading path with one difficult vertical slice
Do not compare a platform demo with a custom-build estimate. Give the leading paths the same representative product, source assets, hard rule, integration seam and acceptance script. The slice should show one valid configuration, one rejected or repaired state, a visible 3D change, an authoritative price or quote handoff where applicable, and an admin change that reaches a controlled preview.
Record the platform plan, enabled modules, browser and device profile, asset version, API fixtures and known substitutions. If a vendor team prepares the proof, ask which steps require services outside the license and which artifacts your team receives. For a custom or hybrid proof, avoid replacing the hardest boundary with a constant. That only proves presentation.
The goal is not to finish a miniature configurator. It is to expose the assumption most likely to reverse the decision: unsupported rule behavior, unacceptable visual treatment, a fragile API seam, an inaccessible interaction, an unworkable authoring process or an exit gap.
Compare the operating model, not the first invoice
A responsible comparison uses the same cost and responsibility buckets for every path. Keep amounts project-specific; this article does not publish example prices or promise a schedule.
Include discovery and specification, platform subscription or usage, custom engineering, implementation services, 3D asset preparation, product-data cleanup, integrations, environments, testing, security review, accessibility work, training, support, monitoring, content changes, vendor increases, browser or commerce changes and eventual migration. Count internal time even when it does not appear on a supplier invoice.
Timeline needs the same discipline. A platform may remove work only where its existing capability fits. Unsupported rules, unfinished assets, data cleanup and integration approvals remain project work. A custom path may reuse mature components. Compare a platform configuration plan, a custom delivery plan and a hybrid boundary plan against the same acceptance criteria.
The team, timeline and delivery-risks guide goes deeper into roles and dependencies. This page keeps the narrower decision boundary: which operating model should carry them?
Put ownership and exit terms in the decision record
Ownership is not one checkbox labeled “IP.” Separate at least these assets and rights:
- product and option identifiers, source data and transformation rules;
- rule definitions, tests, explanations and publishing history;
- source 3D files, web derivatives, materials, mappings and review records;
- buyer-facing code, design files, copy and localization;
- API contracts, adapters, credentials ownership and test fixtures;
- saved configurations, customer data, analytics events and retention rules;
- hosting, domains, deployment, monitoring and incident records; and
- export formats, frequency, fees, transition support and deletion evidence.
Ask for a sample export during selection. Open it, map it back to a representative configuration and identify what is missing. If only rendered images or runtime files leave the platform, call that what it is. If custom source code leaves without product rules, deployment knowledge or asset masters, that handoff is incomplete too.
Contract for change, not just termination. Confirm what happens when an API version retires, a commerce platform changes, a browser capability shifts, the vendor changes a feature or your catalog adds a new rule family. Name who pays, who approves and what evidence reopens acceptance.
Choose the path that fits the evidence
Choose a custom path when the differentiating experience or product logic survives scrutiny, existing products fail a hard requirement, and an accountable team can own the resulting product. “We want full control” is not enough without a maintenance, security, release and support plan.
Choose a platform path when the real product and integration proof fits supported behavior, the contract covers governance and exit needs, and the organization prefers to operate configuration and content rather than the underlying capability. Do not score marketing-roadmap promises as delivered features.
Choose a hybrid path when a clean seam lets you own the differentiating layers and replace or upgrade managed capabilities independently. Hybrid is often worth testing, but it is not automatically safer. Two parties, two release cycles and an undocumented seam can create more ambiguity than either pure path.
If the team cannot describe authoritative rules, source assets, required outputs or operating owners, pause the selection. That uncertainty belongs in discovery, not in weighted ratings. Record the unanswered questions, test the highest-risk one and score again.
Spellexo is relevant owned proof of Double Edged’s product strategy, UX, 3D pipeline, engineering, launch and ongoing operation. Its case study explicitly labels the evidence as live-product capability with no commerce-lift claim and says it does not prove configurator rescue or migration outcomes.[7] Use that operating perspective without copying its hosted-product scope onto a different configurator.
When the unresolved work needs product-specific strategy, UX, 3D production and integration delivery, the custom 3D product configurator service is the commercial route. The decision record should arrive first: hard gates, weighted evidence, proof findings, ownership, exceptions and the reason the selected path is still defensible after launch.
