Signs you’ve outgrown your configurator

For many manufacturers, a configurator is a major step forward. Engineers capture design intent in rules instead of selecting options by hand. Sales teams quote faster, common mistakes disappear and lead times shrink. For a while, it feels like the problem has been solved.

Then the business grows. Product lines expand, customer requests become more specialized, and engineering handles more volume and more variation than the configurator was ever designed for.

The symptoms appear gradually. A few special cases get handled outside the configurator, then a few more, until engineers spend more time working around the system than benefiting from it.

That doesn’t mean the configurator has failed. It has simply reached the limits of the problem it was built to solve. Configurators are built to choose among answers someone has already worked out. Growth brings orders whose answers have to be worked out fresh: a dimension nobody anticipated, a combination nobody planned for, a site that’s different every time.

Each of the signs below is that same mismatch showing up in a different place.

Sign #1: Engineers are constantly creating exceptions

Configurators perform best when products fit neatly into predefined option sets: length A, width B, motor C, accessory D. The trouble starts when customer requirements don’t fit inside those boundaries.

Engineering starts creating override procedures. Temporary workarounds become permanent processes. Special projects get designed by hand because updating the configurator would take longer than engineering the solution directly.

Over time, the exceptions grow until the “standard process” covers only a fraction of the work moving through the business. When your engineers spend more time managing exceptions than executing standards, the system has outgrown its original architecture.

Sign #2: Product complexity is growing faster than the rules

Most configurators depend on explicit rules. If this option is selected, do that. If this dimension exceeds a threshold, apply another rule.

As products evolve, rules don’t just add up. They multiply, because every new option interacts with the ones already there. Hundreds of rules become thousands. Dependencies become hard to follow, and every change carries risk because no one is completely sure what it will affect downstream.

Eventually, the challenge is no longer configuring products. It’s maintaining the configuration engine itself. Many organizations find they’ve built a second engineering department whose job is managing rules rather than designing products.

Sign #3: Design decisions still require engineering judgment

Some decisions can be captured in simple logic. Others can’t. Experienced engineers make trade-offs every day between performance, cost, manufacturability, material use, shipping constraints and assembly requirements. Those decisions are rarely yes-or-no. They’re optimization problems.

Traditional configurators are excellent at choosing among predefined answers. They struggle when the right answer has to be calculated, such as where a component should sit, or how a part should be sized for conditions nobody anticipated. If an engineer still has to apply judgment after the configurator has finished, it’s solving only part of the problem.

Sign #4: Order times have stopped getting shorter

A configurator usually delivers a big drop in design time at first. Then the progress stalls. Each order still takes a fixed amount of an engineer’s time, because the configurator can assemble the parts but can’t work out the design itself. Someone still has to decide where things go, try a layout, check it and adjust it.

That sets a floor on how quickly an order can move through engineering. While volume is steady, the floor goes unnoticed. When customers need shorter lead times, or orders start arriving faster than engineering can turn them around, it becomes the constraint. More rules won’t lower it, because the time isn’t being spent selecting options. It’s being spent on the decisions the configurator can’t make.

Sign #5: You’re generating configurations, not finished designs

Many companies celebrate when their configurator produces a valid configuration. But engineering work often remains. Engineers still build or adjust assemblies, place components, produce manufacturing drawings, prepare cut lists, BOMs and production documentation, and export files into other business systems.

In other words, configuration has been automated, but engineering hasn’t. As volume grows, that downstream work becomes the next bottleneck, and the organization discovers that solving one constraint simply exposed the one behind it.

Sign #6: Growth still means hiring more engineers

This may be the clearest sign of all. Ask a simple question: what happens if project volume doubles next year?

If the answer is “we’ll need to hire more engineers,” automation has stalled at configuration. The most scalable organizations don’t stop at automating selections. They automate engineering execution, so the same team can deliver far more work without a matching increase in headcount.

What comes after the configurator?

At this point, many companies assume the next step is a bigger configurator, a more sophisticated rules engine or another software platform. In our experience, that’s rarely the answer.

The next stage isn’t more rules. It’s using rules to produce engineering outcomes. Instead of selecting from predefined geometry, the system creates geometry to suit each order. Instead of an engineer deciding where components go, the system determines their placement. Assemblies are built automatically, and the output isn’t a configuration but a complete set of engineering deliverables ready for manufacturing.

The focus shifts from automating choices to automating engineering work. Automating choices helps you sell a product line. Automating the engineering is what lets the business scale.

For some products, this was always the case. When every order is unique, such as a product fitted to a site that’s different every time, there’s no fixed set of options for a configurator to choose from. The configurator can still assemble the parts, but a person has to work out the design for every order first. Those products need a system that can predict the design, not just configure it.

Getting there often depends on predictive geometry: systems that work out the likely best design for conditions they’ve never seen before, much as an experienced engineer would. That’s the subject of an upcoming essay.

Years of investment isn’t a reason to stay

The hardest part of outgrowing a configurator usually isn’t technical. It’s that the company has spent years building it. Every rule represents hours of engineering time, and moving beyond the configurator can feel like writing that investment off. So companies keep adding rules, workarounds and people to a system that stopped scaling some time ago.

That’s the sunk cost fallacy at work. The years already spent are gone whichever way you decide. The only question that matters is which path costs less from here: continuing to absorb exceptions, rule maintenance and engineering hours on every order, or moving to a system that removes them.

The investment isn’t lost, either. The most valuable part of a mature configurator isn’t the software. It’s the knowledge encoded in it: the rules, the valid combinations and the constraints your engineers spent years working out. That knowledge is exactly what the next system needs, and it gives you a head start. Moving beyond configuration means building on it, not starting over.

The real question

The question isn’t whether your configurator is working. It’s whether it’s still solving the problem you have today.

One number answers that better than any other: what percentage of your orders go from configurator to manufacturing without an engineer touching them? If that share is low, or shrinking as you grow, the configurator is no longer carrying the load. Your engineers are.

Many manufacturers have achieved real success with rules-based configurators. They’ve standardized products, improved consistency and increased throughput. That success is what got them this far. Getting further means automating the engineering decisions and deliverables that come after configuration, and that’s where the next major gains are found.