Skip to content
heapbyte - A name of excellence

Service · Engineer

Product Configurators

When the price is a function of what the customer measures, a dropdown full of variants is not a product strategy. We build the pricing model first, then the configurator around it.

  • Shopify Online Store 2.0
  • Liquid
  • JavaScript
  • Metafields
Group
Engineer
Starts with
Technical audit
Delivery
Git + staging theme
Handover
Written documentation

01Overview

Most products that look like a configurator problem are not one. If you can write down every purchasable combination — however many there are — Shopify's variant model is the right home for it, and since the per-product limit rose to 2,048 in October 2025 the ceiling that used to force awkward workarounds has probably stopped being your problem. We will tell you that before quoting anything.

A configurator is the right answer when the set is not finite. A curtain cut to a customer's measurements, a shelf priced by depth and length in fractional increments, a panel where price is a function of area and material rate rather than a stored number — none of these have a variant count. No increase to the variant limit will ever make them fit, because enumeration is the wrong model, not an insufficient one.

The work is mostly modelling, not interface. Rates, valid ranges, option compatibility and minimum charges are business rules that change; they belong somewhere versioned and editable rather than hard-coded into a theme. The storefront reads those rules and computes against them. Getting that boundary right is what separates a configurator that survives a price change from one that needs a developer every quarter.

02The problem

Made-to-measure and made-to-order catalogues do not have a variant count. Merchants either restrict what customers can buy so it fits the variant model, or maintain a combination list that grows past the point of usefulness — and in both cases the pricing rule ends up encoded in a theme where nobody can safely change it.

03You will recognise this if

  • Your price is a formula, not a stored number
  • Customers enter measurements rather than pick a size
  • The product needs more than three axes of choice
  • Some options are only valid with certain others
  • Inventory is consumed by area or length, not by the piece
  • Your configurator app stops short of the production handoff

04How we work on it

  1. 01

    Establish which problem you have

    One question decides the architecture: can you write down every purchasable combination? If yes, this is a catalogue restructure and does not need us. If not, the pricing rule is the specification and we start by modelling it.

  2. 02

    Model the rules before the interface

    Rates, dimensional ranges, option compatibility, wastage allowances and minimum charges are captured as data the merchant can edit — metafields or metaobjects where that fits, an external service where the rules are shared with production. Nothing pricing-related is buried in Liquid.

  3. 03

    Compute the price where Shopify will honour it

    How a calculated price reaches the cart depends on your plan, and the honest options differ. On Plus, a Cart Transform function overrides the line price cleanly. Below Plus the alternatives all carry a cost — catalogue pollution, a quantity field that no longer means quantity, or a checkout outside the standard flow — and we choose deliberately rather than by habit.

  4. 04

    Carry the specification through to fulfilment

    Line item properties hold the dimensions, resolved material and the identifiers needed to reproduce the calculation, so an order queried three months later can be explained rather than defended. Private properties are hidden by the theme, which means the theme has to filter them — an unfiltered theme prints your internal codes in the cart.

  5. 05

    Make the constraints visible before checkout

    Variants have no concept of one option restricting another. Conditional availability — a fabric only offered above a certain width, a finish incompatible with a material — is enforced in the configurator and validated again before the line is accepted, so an invalid combination cannot reach the cart by another route.

04What you get

Deliverables, not decks.

  • Pricing and rules model, editable without a deploy
  • Configurator interface with conditional option logic
  • Computed-price mechanism appropriate to your plan
  • Line item property schema carried to the order
  • Order and fulfilment view of the full specification
  • Validation rules enforced before the cart accepts a line
  • Handover documentation for the rule set
snippets/line-item-properties.liquid
1# sections/main-collection.liquid2{% liquid
  paginate collection.products by 243  render 'card-product', lazy: forloop.index > 64{% endliquid %}5 6// above-the-fold budget: 12ms server, 0 CLS

Delivery pipeline

  1. Audit
  2. Scope
  3. Build
  4. QA
  5. Measure

05What changes

Pricing rules the merchant owns
Rates and ranges are data, not code. A price change is an admin edit rather than a developer ticket.
Specifications that survive to production
The dimensions a customer entered arrive on the order in a form the workshop or the ERP can act on, not as a free-text note.
Invalid combinations do not get sold
Compatibility rules are enforced at configuration and validated again at the cart, so the constraint is not merely a hint in the interface.

06How an engagement runs

  1. 01

    Audit

    We establish whether the product is enumerable or computed, and say so plainly. If a catalogue restructure or an existing app solves it, that is the recommendation and there is no project.

  2. 02

    Model

    The pricing rule, valid ranges and compatibility constraints are documented and agreed before any interface work, because that document is what everything else is built against.

  3. 03

    Build

    Configurator, price mechanism and the path from cart line to fulfilment, delivered with the rule set in the merchant's hands and documented for whoever maintains it next.

07Stack

  • Shopify Online Store 2.0
  • Liquid
  • JavaScript
  • Metafields
  • Metaobjects
  • Admin GraphQL API
  • Shopify Functions

09Questions

Product Configurators

Send us the store and the symptom.

A senior engineer reads it, tells you what is actually going on, and scopes only what the evidence supports.