Configure-to-order for products that are made, not picked
Guided steps, options that rule each other in and out, a price that resolves as they choose, and a build tracked from approval to dispatch.
Your product is specified rather than picked off a shelf. Customers send you emails describing what they want, you reply with a price, and the whole thing lives in a mailbox.
Plenty of good businesses do not sell things that exist yet. A cue, a bike build, a machined part, a piece of furniture, a made-to-measure anything. The customer specifies, you quote, and if they agree you make it.
Standard ecommerce handles this badly, because it assumes a product is a row you decrement. Variants get you as far as size and colour and then collapse — a product with six choices of four options each is four thousand and ninety-six variants, of which you will never stock one.
Steps, not a wall of dropdowns
A configuration is a sequence: pick this, then that, then the thing that depends on both. Presenting it as one screen of thirty fields asks the customer to hold the whole product in their head, and most will leave rather than risk specifying something wrong and expensive.
Steps also let the configuration teach. Someone buying a made-to-order product frequently does not know what all the options mean, and a guided sequence can explain each choice at the point it is being made.
Options that rule each other in and out
The real complexity is not the list of choices, it is that choices constrain each other. This joint requires that shaft. That finish excludes this material. Those relationships are the actual product knowledge, and in most businesses they live in one person’s head.
They are expressed as rules between options, so an impossible combination cannot be selected rather than being caught later by whoever reads the order. A customer who configures something unbuildable and pays for it is a refund and an apology; a customer who simply cannot select it never knows there was a problem.
The price resolves as they build
Each choice contributes, so the price shown is the price of what is currently specified — not a starting figure with “from” in front of it. The resolution happens server-side, because a price computed in the browser is a price a determined customer can change.
A build is a record, not an order line
When a configuration is bought, what exists is a build: the full specification, the resolved price, a reference, a promised date and a lead time. It moves through states you can see — approved, in production, quality check, dispatched — and can be rejected with a reason if what was ordered turns out not to be makeable.
That workflow is the part that replaces the mailbox. “Where is my cue” has an answer that does not require anyone to remember, and the promised date is on the record rather than in a reply you sent three weeks ago.
Stock works differently here, deliberately
A configured product does not decrement a finished-goods figure, because there is no finished good. What it consumes is your time and your components, and the constraint on taking another order is your lead time rather than your shelf.
So the honest thing for a made-to-order line is a realistic promised date, and the discipline is keeping the lead time current when the workshop gets busy. Nothing will do that for you.
Available on the API too
The configurator resolves over the API, so a bespoke front end can drive the same rules, the same pricing and the same builds. If you are building a custom site for a maker and want the product logic to live in one place rather than being reimplemented in JavaScript, that is exactly what it is for.
Stop reconciling stock by hand
One catalogue, six channels, one stock figure that stays right.