Building a Product Configurator for an Online Store: Rules, Pricing and 3D

A product configurator is a rules engine first and a preview second: it decides which options can be combined, prices the result on the server, and turns it into a SKU and bill of materials. A desk with 5 widths, 4 tops, 6 colours, 3 frames and 2 cable trays is already 720 combinations, and Shopify caps a product at 2,048 variants by default.

If you would rather have it built for you, see how RAITHub would build this below.

What is a product configurator, and when does an online store need one?

A product configurator lets a buyer assemble a product from options (size, material, colour, add-ons) and see a valid price and preview before ordering. You need one when the options multiply faster than you can list them as variants, when some combinations are impossible, or when the price depends on a formula rather than a lookup.

Typical cases: made-to-measure furniture, blinds and doors, signage, printed packaging, bikes and equipment with compatible parts, and B2B products where a quote must go to a sales rep before an order. If every product has a handful of fixed variants, you do not need a configurator: a normal product page does the job, and the Shopify versus custom decision usually lands on Shopify.

Should I buy a product customizer app or build a configurator?

Buy when your options are visual (text, colours, artwork) and your rules are simple. Build when the rules, pricing or manufacturing output are the business.

Option	Example and cost	Choose this when	Watch out for
Off-the-shelf customizer app	Zakeke, from $69.90 a month plus a 1.9% fee on customised products on Starter, falling to $299.90 and 1.5% on Scale (Zakeke pricing)	Personalised products, a few option groups, a storefront the app already supports	Per-sale fees grow with revenue; complex compatibility rules, formula pricing and BOM output may not fit
Native variants or a template	Shopify product options and variants, on plans from $19 a month billed yearly (Shopify pricing)	Fewer than a few hundred real combinations, fixed prices per variant, no impossible combinations	Variant count explodes; a price formula becomes a spreadsheet of variant prices
Custom configurator	Your own rules engine, pricing service and preview, on your platform or headless on top of one	Dependencies and exclusions, formula or tier pricing, SKU and BOM generation, B2B quotes, ERP or production integration	You own maintenance, testing and the rule data; it needs an engineering owner

Prices checked on 2 October 2026; confirm on the vendor pages before deciding. There is also a middle path: keep your store platform and build only the configurator as a custom service, which is often the lowest-cost route to complex rules.

How do you model option rules like compatibility and dependencies?

Model options as data and rules as data, never as hard-coded if statements in the front end. Three rule types cover most catalogues:

• Requires (dependency). Choosing a 180 cm top requires the heavy-duty frame.
• Excludes (incompatibility). A glass top excludes the cable tray.
• Range constraints. A custom width must be between 100 and 200 cm, in 5 cm steps.

Store each rule with a human-readable message, so the interface can explain why an option is greyed out instead of silently hiding it. Version the rule set: every saved configuration and quote records which rule version it was built against, so a rule change next month does not silently invalidate an order placed today.

For most stores, simple pairwise rules are enough. If you have hundreds of interacting options, look at a constraint solver, but start with the simple model and add complexity only when a real product needs it.

How should a price rules engine work in a configurator?

The price must be computed on the server, from the same rules the browser uses, every time. The browser can show a live estimate, but the server re-validates and re-prices at add-to-cart, quote and checkout, and ignores any price the client sends. This is the same principle that matters for tiered B2B pricing: money rules belong on the server.

Keep money in integer minor units (cents or paisa), apply adjustments in a fixed order (base, then additions, then multipliers, then customer tier, then rounding), and log which rules fired. Below is a minimal TypeScript sketch of validation, pricing, SKU and BOM generation sharing one configuration object.

type OptionId = string

interface Rule {
  kind: 'requires' | 'excludes'
  if: OptionId
  then: OptionId
  message: string
}

type Adjust =
  | { type: 'add'; cents: number }
  | { type: 'multiply'; factor: number }

interface PriceRule { when: OptionId[]; adjust: Adjust }
interface Component { part: string; qty: number }
interface Config { selected: Set<OptionId>; widthCm: number }

export function validate(cfg: Config, rules: Rule[]): string[] {
  const errors: string[] = []
  if (cfg.widthCm < 100 || cfg.widthCm > 200 || cfg.widthCm % 5 !== 0) {
    errors.push('Width must be 100 to 200 cm in 5 cm steps')
  }
  for (const r of rules) {
    if (!cfg.selected.has(r.if)) continue
    const has = cfg.selected.has(r.then)
    if (r.kind === 'requires' && !has) errors.push(r.message)
    if (r.kind === 'excludes' && has) errors.push(r.message)
  }
  return errors
}

export function price(
  cfg: Config,
  baseCents: number,
  perCmCents: number,
  rules: PriceRule[],
): number {
  const applies = (r: PriceRule) => r.when.every((id) => cfg.selected.has(id))
  let cents = baseCents + cfg.widthCm * perCmCents
  for (const r of rules) {
    if (applies(r) && r.adjust.type === 'add') cents += r.adjust.cents
  }
  for (const r of rules) {
    if (applies(r) && r.adjust.type === 'multiply') cents *= r.adjust.factor
  }
  return Math.round(cents)
}

export function sku(cfg: Config, codes: Record<OptionId, string>): string {
  const parts = [...cfg.selected].map((id) => codes[id]).filter(Boolean).sort()
  return ['DSK', String(cfg.widthCm), ...parts].join('-')
}

export function bom(cfg: Config, map: Record<OptionId, Component[]>): Component[] {
  const totals = new Map<string, number>()
  for (const id of cfg.selected) {
    for (const c of map[id] ?? []) {
      totals.set(c.part, (totals.get(c.part) ?? 0) + c.qty)
    }
  }
  return [...totals].map(([part, qty]) => ({ part, qty }))
}

Run the same module in the browser for instant feedback and on the server as the source of truth. Then write table-driven tests: every rule, every price rule, and a handful of real orders with known totals. A configurator without pricing tests is a discount waiting to happen.

Should the live preview be 2D image layers or 3D?

Start with 2D unless shape or fit is what the buyer is unsure about. 2D layered images (a base photo plus transparent PNG or WebP layers per option) are fast, cheap to produce from photography or renders, and work on every device. 3D earns its cost when buyers need to rotate the product, see proportions, or place it in a room.

	2D image layers	3D with model-viewer	3D with three.js
What it is	Stacked images per option	A web component that displays a 3D model with camera controls and AR	A full WebGL library for custom scenes
Assets	One image per option per view	glTF/GLB models	glTF/GLB models, plus your own scene code
Effort	Low	Medium: mostly modelling and material swaps	High: lighting, controls, performance tuning
Choose this when	Colour, fabric and add-on changes on a fixed shape	You want rotate, zoom and AR with little code	Geometry changes with dimensions, or you need custom interaction

Google's model-viewer is an open-source web component for displaying "interactive 3D models on the web & in AR", supported on the last two major versions of evergreen browsers and Safari. three.js loads glTF through its GLTFLoader and supports Draco-compressed geometry through DRACOLoader, which matters when a model would otherwise be several megabytes. A parametric product (a desk whose width really changes) usually needs three.js, because the geometry must be scaled or rebuilt from the configuration rather than swapped as a file.

How do you generate SKUs and a bill of materials from a configuration?

Generate the SKU deterministically from the configuration, so the same choices always produce the same code, and store the full configuration alongside it. A readable pattern such as product code, dimension and sorted option codes is easy for warehouse staff to read and easy to test.

The bill of materials (BOM), the list of parts and quantities needed to make the item, comes from the same option map: each option contributes components, and the totals are summed. That BOM is what goes to production, a supplier or an ERP. If you hold stock of components, reserve them at order time with the same care as finished goods; preventing stock overselling covers the locking and reservation patterns.

Snapshot everything on the order line: configuration, SKU, BOM, price breakdown and rule version. Months later, a support agent or a factory must be able to see exactly what was sold, even after the catalogue has changed.

How do quotes work for B2B configurators?

B2B buyers often configure, then ask for a quote instead of paying. Treat a quote as a frozen, versioned configuration with a price, an expiry date and a status (draft, sent, accepted, expired). Useful rules:

• Approval thresholds. A discount above a set percentage, or an order above a value, needs a manager's approval before it is sent.
• Customer-specific pricing. Tier and contract prices are applied by the server's pricing step, not typed in by hand.
• Re-price on expiry. An expired quote is re-priced against current rules before it can be accepted.
• Quote to order without re-entry. Accepting a quote creates the order from the snapshot, so nothing is retyped.

More on accounts, tiers and credit is in B2B ecommerce platform development.

How do you keep a configurator fast?

A slow configurator loses the sale on the exact page where intent is highest. Interaction to Next Paint (INP), Google's responsiveness metric, is good at 200 milliseconds or less and poor above 500, and a heavy 3D scene or a server round trip on every click can push you over.

• Validate and estimate in the browser. Run the shared rules module locally; call the server only to confirm price at add-to-cart.
• Lazy-load 3D. Show a static poster image first and load the model and library only when the buyer interacts.
• Compress assets. Draco or similar mesh compression, sensibly sized textures, and modern image formats for 2D layers.
• Preload the next likely layer. For 2D, fetch images for the options on screen before the buyer clicks them.
• Cache rule sets. Rules change rarely; serve them as a versioned, cacheable file.

If the rest of your store is slow too, why a Shopify store is slow covers the usual causes.

How long does it take to build a product configurator yourself?

As a rough guide, one experienced full-stack developer can build a 2D configurator for one product family with 5 or 6 option groups, server-side pricing and tests in about 2–4 weeks. Add several weeks for 3D modelling and scene work, and more for ERP or production integration. That is our estimate, not a benchmark.

The main risk of doing it yourself is a mismatch between the price the buyer sees and the price the server charges, or a rule that lets an unbuildable product through. Both cost real money, and both are prevented by one shared rules module and table-driven tests.

Why RAITHub for this?

RAITHub is a founder-led, QA-first software studio in Dhaka, Bangladesh, founded in 2024 by Rupak Amin, working with clients worldwide in English. Its commerce work is custom platforms where pricing and stock rules are enforced on the server.

• Server-side pricing rules in production. Sundor Skin, a client's B2B wholesale platform, prices buyers on four tiers with per-buyer overrides and enforces credit when an order is submitted, backed by 530+ tests.
• Commerce under test. TheSkinProof, the founder's own multi-vendor marketplace, runs 217 API endpoints and 750+ automated tests across 5 portals.
• Honest about the gap. RAITHub has not shipped a 3D product configurator. The 3D guidance in this post is engineering guidance from the libraries' documentation, and a 3D build would be scoped with that stated.

When you don't need us

• Your options are personalisation (names, colours, artwork) on a supported storefront: a customizer app is faster and cheaper to start.
• You have fewer than a few hundred real combinations with fixed prices: native variants are enough.
• You need 3D modelling or product photography: that is a 3D artist's or photographer's work; we integrate their assets, we do not create them.
• You need a native mobile app: RAITHub builds web apps and PWAs only.

How RAITHub would build this

• Rules and pricing service: options, compatibility rules and price rules as versioned data, with one shared TypeScript module used by browser and server.
• Configurator front end: 2D layered preview by default, or model-viewer or three.js where 3D is justified, with lazy loading and an INP budget.
• Order output: deterministic SKUs, BOM generation and a full snapshot on every order line.
• B2B quotes (if needed): versioned quotes with expiry, approval thresholds and quote-to-order.
• Integration: your existing store, a headless storefront, or a custom platform, plus ERP or production export.

Timeline: a fixed-scope configurator for one product family usually fits the 4–6 week MVP range; a configurator with ERP, production and quoting integration is closer to the 6–12 week backend and API range.

You receive: automated tests and CI for every rule and price path, handover docs and runbooks for editing rules, and full IP in the code under NDA.

Next step: book the free 15-minute technical audit with your product, options and pricing logic, and you get a written fixed quote. The ecommerce page shows what a build includes, the marketplace and B2B store guide covers the wider platform, and the API and backend service covers the integration work.

Frequently asked questions

What is a product configurator in ecommerce?

A tool that lets a buyer build a product from options such as size, material and colour, blocks invalid combinations, shows a preview and calculates the price. Behind it is a rules engine that also produces the SKU and bill of materials for fulfilment.

Can Shopify handle a product configurator?

For simple products, yes, with variants or a customizer app. Shopify's default limit is 2,048 variants per product, so products with many option groups, formula pricing or compatibility rules usually need an app or a custom configurator connected to the store.

Should prices be calculated in the browser or on the server?

Both, from the same rules. The browser shows an instant estimate; the server re-validates and re-prices at add-to-cart, quote and checkout, and ignores any price sent by the client.

Is 3D worth it for a product configurator?

Only when shape, fit or proportion is what the buyer is unsure about. For colour and material changes on a fixed shape, 2D image layers are faster and cheaper. model-viewer suits rotate, zoom and AR with little code; three.js suits geometry that changes with dimensions.

How do you stop buyers choosing incompatible options?

Store requires, excludes and range rules as data, check them on every change in the browser, explain each blocked option with a message, and check them again on the server before an order or quote is created.

How long does a custom product configurator take to build?

A fixed-scope configurator for one product family usually takes 4–6 weeks; with 3D, ERP integration and B2B quoting, plan for 6–12 weeks. 3D assets and photography add their own lead time.