Product configurators that let buyers design, see and price your product

No. We generate the model from your product rules rather than from a library of 3D files. A building, for example, can be drawn from its width, length, height and bay spacing, with cladding and openings placed on each wall. Because the geometry follows the data, adding a new size or option is usually a change to the rules, not a new model to commission.

What we do need is the information your estimators already use: the dimensions you offer and the steps between them, the materials and colours, where each opening or accessory can go and how each choice affects the price. Drawings, brochures, price lists and a handful of real quotes are usually enough to start. Photographs of finishes help us match materials on screen.

If you have computer aided design (CAD) files or 3D assets, they can add detail that is hard to describe in rules, such as a distinctive door, handle or fitting. Engineering models are usually far too heavy for a web page, so we simplify them until a phone can display them smoothly.

The team behind GRO built the Noah Building Systems configurator this way. Its steel frames, cladding and openings are generated from each design as the buyer makes it, not assembled from images rendered in advance, and doors are dragged into position on each wall elevation.

Yes, provided it is designed for the phone from the start rather than shrunk from a desktop layout at the end. A buyer may first explore a considered purchase on a phone and return to it later on a larger screen, so both need to work.

Performance comes from decisions made early. We keep models simple enough to draw quickly and load extra detail only when it is needed. Following the approach in the Three.js documentation, we redraw the scene only when something changes rather than continuously, which saves battery and keeps the page responsive while a buyer adjusts a size.

Controls matter as much as graphics. Buttons and steppers need to be large enough to tap. Dragging needs an alternative such as arrows or typed values, and the summary of key figures should stay visible without covering the model. Validation messages sit next to the choice they refer to, where a small screen can still show both.

Some devices cannot display 3D well, or at all. A lighter mode and a plain fallback, such as a flat drawing with the specification summary, let those buyers finish the design and ask for a price. The Noah Garden Rooms configurator, built by the team behind GRO and now in final testing, adds an augmented reality view that stands the design in the buyer’s garden at full size.

An app suits a product that is customised and paid for in a checkout, while a bespoke configurator suits one your team has to quote before anyone pays.

Configurator apps for Shopify and other online stores are built around a basket. Many now add 3D views, pricing rules and quote requests, but they work within the app’s own structure and the store’s product catalogue. They are usually paid for through a monthly subscription, with features and limits set by the vendor. For a customised product sold online, that is often the sensible answer, and we will say so on the first call.

A quoted product needs different things. The buyer is not adding an item to a basket. They are specifying something your team will price, review and often survey. That calls for your own structural and commercial rules, prices that may be indicative, contact details requested at the right moment and a handover to your sales team instead of a payment.

Ownership differs too. Once a bespoke build is paid for, our terms of business assign the bespoke work to you, and any reusable components we bring are licensed so you can keep using and adapting the configurator, including with another supplier. Some businesses need both tools: a checkout for standard items and a configurator for the made to measure range. In that case we agree where each one starts and ends.

Your own product rules stop them, because the configurator checks every choice against those rules as the buyer designs. Every dimension has limits and steps and every option has conditions. Combinations you do not make are either unavailable or corrected with an explanation, such as a window kept clear of a corner or a door removed when its wall becomes too short to hold it.

The explanation matters as much as the rule. A buyer who sees an option disappear without a reason assumes the tool is broken. We write each rule’s message in plain words and show it beside the choice it affects, so the buyer understands the limit and what to do instead. World Wide Web Consortium (W3C) guidance on validating form input makes the same point: people need to be told clearly, and accessibly, when an entry cannot be accepted.

Rules cannot replace engineering judgement. Ground conditions, planning, loads and site access are often beyond what a buyer can tell a website, so we mark every design as subject to your technical review or survey. The quote request can offer the survey directly. The team behind GRO took this approach with Noah Building Systems. Roof structures are offered only within their span limits and fire doors are counted from the longest wall, with at least one for every 25 m. Every design is subject to Noah’s technical review.

It depends mostly on how complete your rules and prices are when the work starts, so we set the timescale in the proposal rather than on this page. The 3D work is rarely the slowest part. Agreeing exactly what the configurator should allow, prevent and price usually is.

The clearest example is recent. The team behind GRO received the Noah Building Systems specification on 23 September 2026, and the configurator was live on the website on 26 September. Changes agreed when Noah’s team reviewed it were on the live site by the following morning. That pace came from a clear and complete specification, and it describes one project rather than a promise for yours.

Scope moves the timescale as much as the rules do. A configurator with several ranges, an automatic PDF quote and detailed CRM work is a larger build than one range with a price on screen. The Noah Garden Rooms configurator, with four ranges and a seven page PDF quote, was a bigger project and is still in final testing.

Cost follows the same drivers: the number of products and options, the complexity of the rules and pricing, outputs such as PDFs and restore links, any augmented reality view, the CRM mapping and the maintenance you need afterwards. Because those vary so widely, we do not publish a starting price. The proposal sets out the scope and the price before any work begins.

Your buyers want to see it before they talk about it

With a made to measure product, the price depends on a specification the buyer has to settle first. Someone choosing a steel building, a garden room or a run of storage has to picture options that are hard to describe in a form: how wide, which roof, where the doors go. A configurator lets them work through those choices in the order they make them and see the result as it takes shape.

For your team, the value is the specification. Each step answers a question an estimator would otherwise ask on the first call, and the finished design arrives complete enough to price or send for review. Compare that with an enquiry that says “please call me about a building” and leaves every detail, and every misunderstanding, to a later conversation.

Of the lead capture tools we build, a configurator asks the most of both sides: your team has to write its rules down, and the buyer has to make a series of decisions. That effort pays back when choices interact and change the price. When a calculator, a guided form or a plain quote request would do the job for less, we say so before anything is built.

What your configurator project includes

Scope starts with what you sell: every size, structure, material, opening and finish in your range, the prices attached and the rules that connect them. We write that product matrix down with the people who quote today and agree it before design begins. It becomes the specification for the build and the reference for checking that a design on screen is one you would actually make.

The build covers the step by step journey, a model generated from the buyer’s choices, visible validation, the price or specification output and the quote request. Depending on scope it can add a design PDF, a link that restores the design and an augmented reality view on supported phones. Each option maps to a field in your CRM. In HubSpot these are custom properties, and how many you can create depends on your subscription.

Testing covers the ordinary routes, the limits of every dimension and the combinations your rules exclude. Your estimators check sample designs and prices against their own recent quotes before launch, and any design they would refuse to quote becomes a new rule or a clearer message. Buyers see the configurator only once those checks agree.

Build the rules first, then the model

We start with the decisions your estimators make without thinking: which roof suits which span, when a second door becomes necessary, which finishes a range can take. Each becomes an explicit rule with a plain explanation the buyer sees when it applies. A design that breaks a rule is corrected or flagged with the reason, rather than accepted quietly and discovered at technical review.

The journey follows the order buyers decide in, usually product type, then size and structure, then openings and finishes, with the key figures always in view. The 3D model is drawn from the design data itself, so the drawing, the dimensions and the price come from one source. When those three disagree, the buyer stops trusting the tool and your team inherits the confusion.

Before launch we submit test designs from a desktop and a phone, check each record in your CRM and confirm the buyer’s emails arrive. Early feedback after launch tends to change defaults, wording and the order of steps, so we plan for that round of changes.

A hypothetical acoustic meeting pod configurator

Consider a hypothetical maker of acoustic meeting pods for open plan offices. Its first calls are spent establishing footprint, seating, glazing, ventilation and whether the pod will fit through the building’s doors and lifts. A configurator could let an office manager choose a size, seat count, glazed sides, door position and finishes while a model shows the pod standing in a simple room.

The company’s own rules would do the work. On some models a glazed wall could not also carry the door. Larger pods could need a ventilation upgrade, and a floor above ground level could prompt a question about lift access. Each rule would appear as a short message beside the choice. The buyer would see an indicative price for the pod as drawn, with delivery and installation assumptions stated next to it.

The quote request would reach the CRM with every choice stored as its own field and any review flags raised. The installer would start the call knowing the pod, the room and the route to it. This example is hypothetical and promises no result. It would be judged on how often a submitted design survives the site check unchanged.

Measure designs, quotes and orders separately

A configurator produces four signals worth keeping apart: a design started, a price reached, a quote requested and an order won. Each tells your team something different, and adding them together hides the step where buyers give up. We define those events before launch and, where tracking is permitted, record where buyers stop, which options they choose and how often a design is changed after review.

The most telling measure is often the gap between the configured design and the final order. If estimators keep reworking spans, openings or finishes, the rules or their wording need attention. If buyers abandon at one step, it may ask for a decision they are not ready to make.

An indicative price from a configurator is not revenue and should never be reported as such. Whether Google Ads or Meta should learn from configurator activity is a separate decision. The usual route is to report the eventual order through offline conversion imports in Scale, once your records show how configured designs relate to closed sales.

Your product needs real options to justify a configurator

A configurator suits products whose options interact and whose price follows the design. Buildings, garden rooms, enclosures, furniture systems and modular equipment are typical. Where only a couple of measurements move the price, a calculator is quicker to build and easier to keep accurate.

Your team supplies the product matrix, the prices or pricing logic, a set of real quotes to test against and a person who can decide when a rule is unclear. Existing CAD files can help with detail but are not required. What usually slows a build is an incomplete rule set rather than the 3D work.

Cost follows the number of products and options, the complexity of the rules, outputs such as PDF quotes and the CRM work. The proposal fixes the scope, states any hosting or licence costs and names who maintains prices after launch, so the configurator stays accurate as your range changes.