Konfigurationslogik, die mit Ihrer Produktlinie skaliert

There's a moment in every product company's life when someone opens the spreadsheet that defines all the valid product configurations and realises it has become sentient. Not literally, obviously. But it has grown to a point where no single person understands all the rules, the columns have multiplied beyond the visible screen width, and there are conditional formatting rules that reference other conditional formatting rules. It has become, in the truest sense, a legacy system. The fact that it lives in Excel doesn't make it any less of one.

This article is about what happens next. Specifically, it's about how to think about product configuration logic when your catalogue grows beyond the point where brute force and tribal knowledge can keep up.

The combinatorial explosion problem

Let's start with some arithmetic that should make anyone selling configurable products slightly uncomfortable.

Say you sell a product with 5 options, each with 3 choices. That's 3⁵ = 243 possible configurations. Manageable. A diligent product manager could review every one of them over a long afternoon.

Now say you sell 20 product families, each with 8 configurable options, each with an average of 4 choices. That's 20 × 4⁸ = roughly 1.3 million possible configurations. Nobody is reviewing those over an afternoon. Nobody is reviewing those, full stop.

This is the combinatorial explosion, and it's the reason product configuration is fundamentally an engineering problem, not an administrative one. The number of possible configurations grows exponentially with each new option you add. Every new colour, every new size, every new accessory doesn't add to the complexity linearly. It multiplies it.

And here's the part that really stings: most of those 1.3 million configurations are probably invalid. The matte finish isn't available in the compact size. The premium motor can't be paired with the entry-level controller. The outdoor mounting kit requires the weatherproof enclosure. Your job isn't just to enumerate what's possible; it's to enforce what's allowed.

Why if/else chains break at scale

The first instinct, and it's a perfectly reasonable one, is to encode configuration rules directly in code. If the customer selects option A, disable option B. If they pick the large frame, show the heavy-duty bracket options. Simple, readable, works.

It works until it doesn't. And the point at which it stops working arrives faster than most teams expect.

The problems with hardcoded configuration logic are well-documented and predictable:

• Rule sprawl: What starts as 20 tidy if/else blocks becomes 2,000 tangled conditionals spread across multiple files. Nobody wants to touch them. The original author has long since moved on. Comments like "DO NOT CHANGE THIS" appear with alarming frequency.
• Cross-cutting rules: Some rules apply across product families. When those rules are embedded in product-specific code, changing them means finding and updating every instance. You will miss at least one. You always miss at least one.
• Testing difficulty: How do you test 1.3 million configurations? You don't. You test the ones you can think of and hope for the best. This is not, strictly speaking, an engineering strategy.
• Business agility: Adding a new product variant requires a code change, a review, a deployment. That might be fine if you release new variants quarterly. If you're doing it weekly, you've turned your product team into a deployment queue.

The alternative is a rules engine: a system where configuration constraints are expressed as data rather than code. Rules become records in a database or entries in a structured file, managed through an interface rather than an IDE. Product managers can add and modify rules without waiting for engineering cycles. The rules themselves become testable, versionable, and auditable independently of the application code.

This isn't a new idea. Production rule systems have been around since the 1970s, and modern business rules engines like Drools have been handling exactly this class of problem in enterprise software for decades.^[1] What's changed is that the same principles now apply to customer-facing product configurators, where response time is measured in milliseconds and the user experience can't tolerate a "please wait while we validate your selection" spinner.

Constraint satisfaction: modelling what goes with what

At its core, product configuration is a constraint satisfaction problem (CSP). You have a set of variables (the configurable options), each with a domain of possible values (the choices available for each option), and a set of constraints (the rules governing which combinations are valid).

This framing is more than academic. It gives you a well-studied mathematical foundation with decades of research behind it, plus efficient algorithms for solving exactly the kinds of problems that product configuration throws at you.^[2]

In practice, configuration constraints tend to fall into a handful of categories:

• Requires: Selecting option A means option B must also be selected. The panoramic sunroof requires the reinforced roof frame. The API integration module requires the enterprise licence tier.
• Excludes: Selecting option A means option B cannot be selected. The wall-mount bracket is incompatible with the portable base. The basic controller can't drive the high-resolution display.
• Conditional availability: Option B only appears as a choice when option A has a specific value. The colour options for the premium finish are different from the standard finish. The accessory catalogue changes based on the base model.
• Cardinality constraints: You can select at most three accessories from this group. Every configuration must include at least one power supply option.

The power of modelling these as formal constraints, rather than ad hoc code, is that constraint solvers can do useful things automatically. They can propagate implications: if the user selects the outdoor kit, the system can immediately narrow the available enclosure options to only those that are weatherproof, without anyone having written an explicit rule for that specific interaction. They can detect unsatisfiable states: if no valid configuration exists given the current selections, the system can identify which choice caused the conflict and suggest alternatives.

The best configuration systems don't just prevent invalid choices. They guide the user toward valid ones.

The real-time pricing puzzle

If you thought configuration rules were complicated, wait until you add pricing.

In a simple world, every option has a fixed price, and the total is the sum of the parts. In reality, pricing in configurable products is almost never that straightforward. You're dealing with:

• Dependent pricing: The cost of option B changes based on which option A was selected. The same motor costs more when installed in the compact frame because the mounting hardware is different.
• Volume discounts and tiering: Buy 10 units, the per-unit price drops. But only for certain configurations. And only if the order is placed before the end of the quarter. And only for customers on the preferred pricing tier.
• Bundle pricing: Options A, B, and C together cost less than A + B + C individually. The system needs to detect when a bundle applies and calculate the savings automatically.
• Currency and regional pricing: The same product in the same configuration has different pricing in different markets, and those differences aren't just exchange rate conversions.

All of this needs to happen in real time, as the user makes selections. A McKinsey study on B2B pricing found that companies using dynamic, data-driven pricing approaches saw margin improvements of 2 to 7 percent.^[3] But those improvements only materialise if the pricing logic can keep up with the configuration logic. If the user has to click "calculate price" and wait, or worse, submit a configuration and wait for a quote, you've lost the real-time feedback loop that makes configuration tools genuinely useful.

The architectural challenge here is that pricing and configuration rules are deeply intertwined but need to be maintained by different people. Product engineers define what's compatible. Pricing teams define what things cost. When those two rule sets live in the same tangled codebase, you get turf wars, deployment conflicts, and the special joy of a pricing change accidentally breaking a compatibility rule.

The data model question

Underlying all of this is a deceptively simple question: how do you structure your data?

Get the data model wrong and every feature you build on top of it will be a fight. Get it right and things that seemed impossibly complex become almost boring to implement. (Boring is good. Boring is what you want in infrastructure.)

A configuration data model typically needs to represent:

1. Product families and models: The hierarchical structure of your catalogue. A family contains models; models contain option groups; option groups contain options.
2. Option definitions: The available choices, their metadata, their display characteristics, and their relationships to each other.
3. Rules: The constraints governing valid combinations, expressed in a way that's both machine-evaluable and human-readable.
4. Pricing layers: Base prices, option prices, adjustments, discounts, and the conditions under which each applies.
5. Versioning: Because your product line changes over time, and a quote generated last month needs to reference the rules and pricing that were in effect when it was created, not today's rules.

The temptation is to model this relationally, with foreign keys pointing everywhere and join tables for every many-to-many relationship. That works for persistence, but it's miserable for evaluation. At runtime, you want a denormalised, in-memory representation of the relevant rules and options, structured for fast traversal rather than storage efficiency.

This is a common pattern in systems that need both flexibility and performance: store normalised, evaluate denormalised. Your database keeps the canonical, maintainable representation. Your runtime gets a precomputed, optimised version that's been flattened and indexed for the specific access patterns your configurator needs.

Keeping it fast when the rules get complex

Performance in product configuration isn't just a nice-to-have. It's a core requirement. When a user changes a dropdown selection, they expect the available options, the pricing, and the visual representation to update instantly. "Instantly" in human terms means under 100 milliseconds. That's not a lot of time to evaluate potentially thousands of rules.

Several techniques help keep things responsive:

Rule indexing and precomputation

Not all rules are relevant to every selection. If the user changes the colour, you don't need to re-evaluate rules that only involve motor types and controller compatibility. Indexing rules by the options they reference lets you evaluate only the subset that's actually affected by the current change.

Incremental evaluation

Rather than re-evaluating the entire rule set from scratch on every change, track which rules were satisfied or violated before the change and only re-evaluate those whose inputs have changed. This turns an O(n) problem (where n is the total number of rules) into an O(k) problem (where k is the number of rules affected by the change). For large rule sets, this difference is dramatic.

Client-side evaluation

For configurators embedded in web applications, shipping the rule set to the client and evaluating locally eliminates network round trips entirely. This requires the rule set to be compact enough to transfer and the evaluation logic to be simple enough to run in the browser, but for many product catalogues, it's entirely feasible. The rule data for even a complex product family typically compresses to a few hundred kilobytes.

Caching valid states

For product families with a bounded (if large) configuration space, precomputing the valid states and caching them can eliminate rule evaluation at runtime entirely. This trades storage and precomputation time for instant lookups. It's not feasible for truly enormous configuration spaces, but for many real-world products, the set of valid configurations is much smaller than the theoretical maximum.

The human side of configuration engineering

It's easy to get lost in the technical details of constraint solvers and data models and forget that the point of all this machinery is to help a human being choose the right product. The best configuration logic in the world is useless if the interface that exposes it is confusing, slow, or requires a PhD in your product catalogue to navigate.

Research from the Baymard Institute on e-commerce UX has consistently found that overcomplicated product customisation flows are a significant driver of cart abandonment.^[4] Users don't abandon because they can't find what they want. They abandon because the process of specifying what they want is too exhausting.

This means the configuration engine needs to do more than just validate. It needs to guide. When a user makes a selection that narrows their remaining options, the interface should make that clear. When a selection would lead to a dead end (no valid configurations possible), the system should warn before the user gets there, not after. When the user is overwhelmed by choices, the system should offer sensible defaults and common configurations as starting points.

In other words, the technical architecture serves the user experience, never the other way around. If your constraint solver is elegant but your users can't figure out how to configure a product without calling your sales team, you've solved the wrong problem.

Where this is heading

Product configuration is one of those domains where the complexity is genuinely irreducible. You can't simplify away the fact that your products have many options with intricate interdependencies. What you can do is manage that complexity with the right abstractions: rules engines instead of hardcoded logic, constraint satisfaction instead of manual validation, layered data models instead of monolithic spreadsheets.

The companies that get this right gain a real competitive advantage. They can launch new product variants faster because adding a variant means adding data, not writing code. They can empower their sales teams with self-service configuration tools that produce accurate quotes in minutes instead of days. They can embed configurators directly into their websites, letting customers explore options without waiting for a sales call.

The companies that don't get this right end up with the spreadsheet. You know the one. It's on a shared drive somewhere, it has 47 tabs, and the person who understands how it works is on holiday. Again.

Choose the rules engine.