What a 41-Option Configurator Requires
In a configurator, the work is in the rules: which options exclude each other and which combinations change the price. We built one for a prefab-garage manufacturer with 41 options. At that size, dependencies have to be modelled as data, because hard-coded if-statements break as soon as a new option is added.
Dependencies as data
With a few dozen options, the possible combinations are too many to list, so they are validated instead. Each option, its dependencies and its exclusions are stored as data and checked against the current selection on every change.
The problem that matters most is a stale selection. An option reveals a second field, something is chosen there, then the first option changes and that choice is no longer valid. If validation only runs forward, the stale choice stays in the order and gets priced. So the whole configuration is re-checked after every change, and anything that is no longer valid comes off the total visibly, so the customer can see why the total changed.
Validation also runs in two places: in the browser, so the form answers immediately, and on the server, because the visitor can change what runs in the browser. That is one rule set checked twice, and the two checks can drift apart. A server round trip on every click would avoid that but makes the form feel slow on a weak connection. Keeping both checks in agreement as rules change is the hard part; if they disagree, the total jumps when the customer submits.
Pricing by combination
Most options add a fixed amount. Some prices depend on a combination of options, so a price rule has its own model: a condition over the whole configuration and the change it makes to the price.
The arithmetic has to be exact and repeatable. Money is calculated in cents as integers, and the result is stored with net and gross amounts and the VAT rate. The same configuration submitted twice must produce the same price, also after a rule is edited. So price rules are versioned, and each quote records the version it was priced with. Otherwise a routine price update would change the history of every quote already sent.
The rules also have to stay readable for whoever maintains them. An editor that can express any rule can also express contradictory ones, so we limit it to the rule types the engine supports. A new type of rule is a code change.
The quote as a document
Document generation is the second requirement that is easy to underestimate. Buyers forward the quote to their own customers or attach it to a tender, so it is a branded PDF with a reference number, the selected specification, the price and the terms. That PDF is generated on the server.
Printing from a browser makes the output depend on the machine that printed it: fonts, page size, whatever the operating system substitutes. A forwarded document has to be identical in every copy, so it has to be rendered server-side, where the fonts are fixed. A bilingual site adds a constraint: the layout has to hold in both languages.
Reference numbers need care too. A double click, or a retry after a timeout, must not create two reference numbers for the same configuration, so a repeated request returns the existing quote. A stored quote carries:
the full selected configuration
the price rule version it was priced under
the currency and VAT rate as stored values
the reference number with its timestamp, and the rendered document
We keep the configuration and the PDF together. If a customer questions a quote a year later, the configuration shows how the price was calculated and the PDF shows what was sent.
Payoff and cost
Once it runs, staff no longer price every enquiry by hand, and quotes go out without a pricing round in between. The manufacturer can change prices and add options of a type the engine already supports; new rule types are added by us.
The cost is that this is an application: a relational model of options and the rules between them, with calculations running on a server. Hosted website tools render pages and have no place for that model, so it runs on our own stack: Next.js, Spring Boot, PostgreSQL, Flyway migrations and Docker images. That is more to maintain than a hosted site.
It also means the scope is written before work starts. The acceptance criteria are the number of options, the rule types the engine supports, what the PDF contains and what stays editable afterwards. We work to a written scope at a fixed price with the agreed revision rounds, and that only holds if this line is drawn first.
Adding these after the first quotes have gone out means reopening the pricing logic and the stored documents.
How we scope and price this kind of work is on the services page.
