Your Configurator Is Not the Problem. Your Architecture Might Be.

There is a familiar moment in manufacturing.

Sales wants to send quotations faster. Engineering wants fewer interruptions. IT wants something maintainable. Finance wants a business case that doesn't involve the phrase "we'll figure that out later."

Then someone asks a perfectly reasonable question:

"Should we just build our own configurator?"

Someone else suggests buying a CPQ system. A third person mentions an existing platform. Before long, the meeting has turned into a debate about software, licenses, APIs and whether the current ERP system can somehow do everything.

Meanwhile, the actual problem remains untouched.

Customers are waiting for quotations. Engineers are checking configurations that look suspiciously similar to the ones they checked last Tuesday. And sales is still asking Bob in engineering whether that particular combination of components will work.

Bob knows the answer. Bob always knows the answer.

That's precisely the problem.

Build vs. buy: the wrong question to start with

Building your own software sounds attractive for good reasons.

You control the functionality. You can tailor the experience to your products. You aren't forced to organise your business around someone else's idea of how things should work.

And if your products are genuinely complex, those things matter.

But building software is not a one-time event. It creates an ongoing responsibility for development, maintenance, security, infrastructure and everything that happens when the business changes.

Your product range evolves. Pricing changes. New markets appear. ERP systems get upgraded. The developer who wrote the clever bit of code five years ago may now be doing something entirely different.

Congratulations. You now own a software product as well as a manufacturing business.

Buying software has its own advantages. Established functionality, existing infrastructure and a maintained product can save considerable effort. But a platform that works beautifully for standard catalogue products may struggle when your product is engineered around a complicated set of technical rules.

And the most expensive limitation is not necessarily a missing feature.

It's discovering that your entire process must change to accommodate the software.

Neither approach is inherently right or wrong. The decision depends on your products, your competitive advantage, your internal capabilities and the complexity you actually need to support.

Which brings us to a more useful question:

What should you own, and what should you stop rebuilding?

The third option: buy the foundation, build the advantage

The choice is not always between buying an off-the-shelf system and developing everything from scratch.

There is a middle ground.

Use an established platform for the capabilities it handles well. Build the product-specific logic, visual experience, integrations and workflows that make your business different.

Think of it as building a house.

You probably don't want to manufacture your own bricks, develop a new electrical standard and invent a plumbing system before you can move in. But you might want an unusual floor plan.

Software works in much the same way.

A suitable platform can provide the foundation. Your own application logic can handle the parts that require deep knowledge of your products and processes.

For one manufacturer, that might mean a visual configurator that allows dealers to design a warehouse layout. For another, it could be an application that configures machinery, validates component combinations and produces accurate technical documentation.

The underlying technology doesn't need to be unique.

The way you turn your product knowledge into a competitive advantage might be.

Of course, the middle ground is not automatically the cheapest or simplest option. It depends on the platform's extension points, licensing model, integration capabilities and how much custom development is required.

The objective isn't to avoid building software. It's to be deliberate about what you build.

CPQ vs. engineering automation: they solve different problems

Let's say you manufacture configurable industrial products.

A customer wants a solution. Your sales team needs to understand the requirements, select the right components, calculate a price and send a quotation.

This is where CPQ comes in.

CPQ stands for Configure, Price, Quote. It helps businesses manage product choices, configuration rules, pricing and quotation workflows.

A good CPQ process can prevent incompatible selections, apply commercial rules consistently and reduce manual work between a customer enquiry and a quotation.

But there is an important distinction.

Knowing what you're allowed to sell is not always the same as knowing how to engineer it.

Consider a manufacturer of pallet racking.

A salesperson needs to configure a warehouse layout. The system must account for the dimensions, available components, product compatibility and pricing.

That is already more complicated than selecting a product from a dropdown menu.

Now introduce the engineering requirements.

Which beam profile is appropriate for the load? Does the configuration satisfy the relevant structural requirements? Are the selected components suitable for the intended application? What calculations or checks are required before the design can be approved?

These questions involve engineering knowledge, not just commercial rules.

Some CPQ systems can handle sophisticated technical constraints and calculations. Others focus primarily on product selection, pricing and quotations. Likewise, engineering automation can exist as a separate application or be integrated directly into the configuration workflow.

The labels alone don't tell you what a system can do.

What matters is whether the software can represent and apply the actual rules governing your products.

A practical way to distinguish the two

These capabilities overlap. They don't need to live in separate products, and there is no universal architecture that every manufacturer should follow.

The point is that they solve different parts of the problem.

If you evaluate software based only on its ability to generate a quotation, you may miss the engineering work that happens before that quotation can safely be issued.

And if you focus exclusively on engineering calculations, you may overlook the sales experience that determines how easily customers and dealers can use the result.

The opportunity lies in connecting the two.

The real bottleneck is often the handover

Imagine your current sales process.

A customer sends a request. Sales interprets the requirements. Someone builds a preliminary configuration. Engineering checks it. Sales adjusts the proposal. Engineering checks it again. A component changes, the price changes, and someone updates the quotation.

None of these individual tasks is necessarily unreasonable.

The problem is the repeated handover of information and decisions between people and systems.

Engineers spend time checking routine configurations. Sales waits for answers to questions that have already been answered many times. Product knowledge lives in spreadsheets, documents and people's heads.

You can buy a new CPQ system and still have this problem.

You can build a beautiful 3D configurator and still have this problem.

You can introduce AI and still have this problem.

If the underlying product rules are missing, the data is unreliable or the workflow is poorly designed, adding another interface doesn't magically fix it.

The goal should be to move repeatable decisions into a controlled, maintainable process.

Where a configuration can be validated automatically, let the software do it. Where a calculation can be standardised and verified, make it reusable. Where a decision genuinely requires engineering judgement, keep the engineer involved.

The objective is not to remove engineers from the process.

It's to stop using expensive engineering expertise for work that the business already knows how to do.

So what should you actually build?

Before choosing a platform, launching a development project or sending out an RFP, ask five questions.

1. Where does the process actually slow down?

Map the journey from customer enquiry to quotation and delivery. Find the queues, repeated checks, duplicated data entry and manual decisions. Start with the bottleneck, not the technology.

2. Which decisions are repeatable?

Separate straightforward commercial rules from technical calculations and decisions that require expert judgement. Identify what can be automated reliably and who is responsible for validating it.

3. What is genuinely unique about your business?

Your product knowledge, engineering methods and customer experience may be differentiators. Authentication, infrastructure and standard data exchange may not be. Don't assume every component needs to be developed internally.

4. What happens when the business changes?

Ask how easily the solution can accommodate new products, new rules, additional integrations and new markets. Consider ongoing ownership, licensing, maintainability and dependency on individual developers or vendors.

5. Can you start small without painting yourself into a corner?

You don't necessarily need to automate every product family and every process on day one. A focused first phase can prove the approach with a real product category and real users, while establishing a foundation that can be extended later.

The architecture should support the next step without requiring you to solve every future problem upfront.

The best architecture is the one that solves the business problem

There is no universal winner in the build-vs-buy debate.

Sometimes a standard CPQ solution is exactly what you need. Sometimes a custom application is justified. Sometimes the right answer is a visual configurator connected to engineering calculations, an ERP system and a dealer portal.

And sometimes the first thing you need to fix is the process itself.

Technology should follow the problem.

At NorrLab, we work with manufacturers whose products require more than a simple selection of options. We build visual product configurators and connected software that bring product knowledge, configuration rules, engineering automation and business systems together.

The objective isn't to sell you the biggest possible software project. It's to identify where better digital tools can remove friction from selling, configuring and delivering your products.

Because the most impressive configurator isn't necessarily the one with the most features.

It's the one that helps your business make the right decisions, faster — without asking Bob to check everything.

Product Configuration. And Beyond.

Want to find out where configuration and automation could make a difference in your business? Let's start with the process, not the software.