Product Rules Belong in Data. Computation Belongs in Code.

Every configurator project reaches the same fork early on: where does the product logic live? The answer decides who can change your products later, how fast the system runs — and whether you own your rules or rent them from a supplier.

What a product rule actually is

Your option set, the dependencies between options, component deltas, part number logic and prices are declarations. They describe your products. They change often — with every new series, every price round, every discontinued component — and they belong in data that your own engineers can read, check and change.

Written into application code, the same rules can only be changed by whoever wrote them. Every price update becomes a ticket, every new variant a development task. You are renting your product logic rather than owning it.

And what is not a rule at all

This is the half of the question that usually gets skipped. Hydraulic sizing, deriving a duty point from a system curve, generating geometry, resolving a configuration against thousands of constraints — none of that is a declaration. It is computation, and it belongs in code: written once, tested, and fast.

Why “no code needed” is a warning sign

Many configurator platforms promise that everything can be expressed in their rule language. It sounds like freedom. In practice, a rule engine that tries to replace a programming language reaches only a fraction of what the language can do — and the gap gets filled with workarounds: rules that encode calculations, conditions nested to make up for missing operations, a model nobody can read any more.

The result is a system that is permanently almost finished, with a growing list of things it cannot do. And it gets slow, because every evaluation walks through logic that should have been a single function.

A supplier who claims the whole thing is configuration and no code is needed is describing a limitation, not a feature.

Where to draw the line

A simple test helps:

• If it describes what exists — options, variants, prices, part numbers, compatibilities — it is data.
• If it calculates something — a size, a curve, a load, a geometry — it is code.
• If it changes with every price round or product launch, it must be editable without a developer.
• If it must be fast and exact under load, it must not be interpreted rule by rule.

Good systems keep both halves apart and connect them cleanly. The data says which pump series, impellers and motors exist and what they cost. The code calculates which combination meets the duty point. Neither tries to do the other’s job.

What to ask before you buy

Ask your supplier — and ask us — which parts of your requirement would be declarative data and which would be code, and expect a clear line between them. Ask who can change the data after go-live, and how long a price change takes from decision to quotation. If the answer involves a support ticket, you already know who owns your product logic.