Adding a multi-language field to the backend takes an afternoon. The part that takes months sits in …
Build, Buy, or Compose: Running a Product Configurator Without Locking In Your Storefront
Every product configurator conversation eventually turns into a build-versus-buy debate, and most teams resolve it as if it were a one-time fork: write custom logic, or install a vendor. That framing misses the option that actually protects a storefront over multiple years, compose. Instead of asking whether to build or buy the configurator, the more useful question is where the configuration state, the pricing rules, and the rendering layer are each going to live, and whether any of them can move without a rebuild.
This piece is about that decision axis specifically. If you are trying to fix Core Web Vitals on an existing configurator, our patterns post on configurators and Core Web Vitals covers client-side option state, price recalculation, and layout shift. If you are wiring a configurator into a Magento storefront specifically, the Magento integration comparison walks through native configuration, widgets, and a decoupled frontend layer. This post sits above both: it is about how to make the build, buy, or compose decision so the answer still holds after your next backend change.
Where configurator lock-in actually lives
Lock-in from a configurator rarely shows up as a single contract clause. It shows up in four places, and each can move independently of the others:
- Configuration rules: which options are valid together, which combinations are excluded, how dependencies cascade (choose this fabric, that leg style disappears).
- Pricing logic: how a base price plus selected options becomes a line-item price, including quantity breaks and B2B-specific pricing tiers.
- Session and cart state: how a customer's in-progress configuration becomes a cart line, and what happens if they leave and come back.
- Rendering: whether the visual output is a 3D viewer, a 2D image swap, or a form with a live price, and what markup or script tag it requires on the page.
A build, buy, or compose decision changes who controls each of those four, not just who writes the initial code. That is also why the three paths are not mutually exclusive. A mature setup usually mixes them, buying the rendering engine while owning the rules and pricing layer.
Path 1: Build
Building means your team owns the configuration state machine, the price calculation, and typically the rendering, inside your own frontend code. For simple option sets (a handful of independent attributes, no cross-dependencies, no 3D), this is often the cheapest path to maintain and the one with the least lock-in by definition: there is no vendor to move away from.
The trade-off shows up as complexity grows. Cross-dependent rules (this option excludes that one, this combination triggers a surcharge) turn into a rules engine your team now maintains indefinitely. 3D or photorealistic rendering is a specialized discipline; building it in-house is a real project, not a sprint. And because the logic is custom, every backend integration, such as pricing sync or inventory-aware option availability, is also custom, which is its own long-term cost even though it avoids vendor contracts.
Build is the right default when the option set is small and stable, when 3D rendering is not required, and when the team has capacity to own a rules engine over multiple years.
Path 2: Buy
Buying means installing a vendor configurator, most commonly Threekit for 3D visual commerce or Zakeke for 2D and hybrid product customization, and letting it manage rules, pricing, and rendering as one package. Both vendors ship an embeddable player: Threekit's player is loaded via a script and exposes a configurator API through `player.getConfigurator()`, and Zakeke exposes a Configurator UI API plus a server-to-server Cart API for the checkout handoff.
Buy is fast. A working 3D or 2D configurator can be live in weeks instead of months, and the vendor absorbs the maintenance of the rendering engine, which is genuinely hard to build well. The trade-off is that the rules and pricing configuration typically live inside the vendor's authoring tool, not in your codebase. That is fine as long as the vendor remains the right fit. If you outgrow it, migrate backends, or need the configurator embedded differently than the vendor's default player allows, the rules and pricing configuration usually have to be rebuilt on the new side, because they were never expressed in a system you control.
Buy is the right default when 3D or photorealistic rendering is a requirement, when time to market matters more than long-term portability, and when the option catalog changes often enough that a non-technical team needs to maintain it in a vendor's authoring UI.
Path 3: Compose
Composing means using a vendor's API rather than its default embedded player, and rendering the configurator inside your own frontend layer. Both Threekit and Zakeke support this: Threekit ships a REST API SDK and a composable configurator SDK alongside the player, and Zakeke's documentation describes API integration for platforms outside its supported list, using the Cart API and Product Catalog API directly. The vendor still owns rule authoring and, in Threekit's case, the rendering engine itself. What changes is where the UI lives and how the result reaches your cart.
The practical difference from buy: instead of a script tag or iframe dropping a fixed player into a page, your frontend calls the API, renders the option UI and pricing in your own components, and only hands the vendor the rendering-heavy parts it is actually good at, the 3D viewer or the photorealistic preview. Cart and checkout stay entirely inside your storefront's normal flow instead of depending on the vendor's embed behavior. If you later swap commerce backends, the configurator API call is one integration among others in your orchestration layer, not a page-level dependency baked into a specific theme.
Compose costs more upfront than buy, roughly the difference between dropping in a widget and building an API integration, but it keeps the parts of the configurator experience that touch your storefront's core flows, cart, pricing display, checkout handoff, inside your own architecture rather than inside a vendor's markup.
A decision framework
None of the three paths is universally correct. What should actually move the decision:
- Option complexity. Leans build: Low, few dependencies. Leans buy: High, needs authoring UI for non-devs. Leans compose: High, but engineering owns integration.
- Rendering need. Leans build: Text or image swap only. Leans buy: 3D or photorealistic required. Leans compose: 3D or photorealistic required.
- Team capacity. Leans build: Engineering owns a rules engine. Leans buy: Marketing or product manages options. Leans compose: Engineering integrates, business authors rules.
- Backend stability. Leans build: Backend unlikely to change. Leans buy: Backend stable, speed matters most. Leans compose: Backend change plausible in 12 to 24 months.
- Checkout ownership. Leans build: Full control needed. Leans buy: Vendor's cart handoff is acceptable. Leans compose: Cart and checkout stay in your storefront.
The row that matters most for this post is backend stability. If a backend migration is plausible, even one you are not planning yet, compose is the path that keeps the vendor relationship without making it a page-level dependency.
What compose looks like inside a composable frontend layer
This is where the pillar-3 framing matters: a Composable Digital Experience Platform treats the configurator vendor the same way it treats a commerce backend, as a system connected through an API contract rather than embedded through markup. Laioutr's Composability & Orchestration layer is where a configurator's API calls sit alongside product, pricing, and inventory calls, so a rendering vendor swap or a backend swap touches one integration point instead of a page template.
For B2B storefronts specifically, where made-to-order products and tiered pricing are common, the B2B Growth Kit covers the surrounding patterns, quote requests and tiered pricing display, that a composed configurator needs to plug into. And if the storefront in question runs on Magento, Headless Frontend for Magento 2 is the entry point for how the same GraphQL-first approach applies to that backend, with the configurator-specific integration paths covered in the companion post linked above.
Composed configurators also make it easier to keep the workflows described in Solutions: Configurators & Checkout Flows intact end to end, because the handoff from configuration to cart never leaves your own checkout implementation.
Our take
Build, buy, and compose are not stages of maturity, they are three different answers to the question of where you want the switching cost to sit. Build puts it in your own maintenance backlog. Buy puts it in the vendor relationship, cheaply until you need to change something the vendor's player was not built for. Compose puts the switching cost in a single, visible integration point, which is the version worth paying more for once you are planning to survive a backend change or a rendering vendor change without redoing the storefront around it.
Frequently asked questions
Do I need to compose from day one, or can I start with buy and migrate later? Starting with a vendor's default player is a reasonable way to validate demand quickly. The migration to a composed setup later is realistic if the vendor exposes an API alongside its player, which both Threekit and Zakeke do. It gets harder if the initial build leaned on vendor-specific markup deep inside page templates rather than an isolated component.
Is compose always more expensive than buy? Upfront, yes. You are building an integration instead of dropping in a script tag. Over a multi-year horizon that includes at least one backend or rendering change, compose is often cheaper, because the rebuild scope on change is smaller.
Can I compose with a build-your-own rules engine instead of a vendor API? Yes. Compose describes an architectural pattern, keeping rules, pricing, and cart handoff inside your own frontend layer, not a specific vendor relationship. A custom rules engine rendered inside your own components is the build path expressed in a composable way, and it is a valid choice when the option set does not need 3D or photorealistic rendering.
Next steps
If you are choosing a path for a new configurator, or reconsidering one that is currently tied to a specific theme or backend, book a 30-minute demo. We will look at where your configuration rules, pricing, and rendering currently live and what a composed setup would change.
More from the Laioutr platform
About the author: Marcel Thiesies is Co-Founder of Laioutr and works with commerce teams on frontend architecture decisions meant to survive a vendor or backend change.