Configurator projects are judged on the demo. The demo is the easy part.
The configurator is a fraction of the work. Everything around it — the data, the infrastructure, the release process, the governance, the people who keep it current — is where the effort and the cost actually sit. The common pattern is a company that gets the configurator working somehow, keeps pushing, and eventually shelves the project after spending a multiple of what the configurator was ever quoted at. Very few of those projects failed on the configuration logic.
What decides whether the tool is still useful in three years is all of that surrounding work. These questions are the ones we see cause trouble later when they are not asked early.
Use them on us too.
Part 1 · Questions 1–7
The rules
Who owns the product logic, how it changes, and whether you can prove what was true on the day you quoted.
01
Which of your product rules are held as data?
Your option set, component deltas, part number logic and prices are declarations — they describe your products, they change often, and they belong in data your own engineers can read, check and change. Written into application code, they can only be changed by whoever wrote them, and you are renting your product logic rather than owning it.
02
And which parts are not rules at all?
This is the other half of the question, and the one that gets skipped. Hydraulic sizing, deriving a duty point, generating geometry, resolving a configuration against a large constraint set — none of that is a declaration. It is computation, and it belongs in code.
Watch for a supplier whose answer is that everything is expressed in their rule language. A rule engine that tries to replace a programming language reaches a fraction of what the language does, 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 now walks through logic that should have been a function.
It is the difference between understanding an engine and building one. Understanding it is worth doing; rebuilding it from scratch, when a proven one already exists, is how projects lose a year.
Ask which parts of your requirement would be declarative data and which would be code, and expect a clear line between them. A supplier who claims the whole thing is configuration and no code is needed is describing a limitation, not a feature.
03
Who may change a rule, and does the system enforce it?
Authority over the rules sits with your company — with engineering, sales, purchasing and everyone else who owns a part of the product data and the rules behind it. That part is rarely disputed. What often is: which steps a change passes through, who signs it off, and whether the tool enforces that sequence or trusts everyone to follow it. A rule that can be edited straight into production is not governed, however the process reads on paper.
04
How much should a user be able to change, and what stops them breaking it?
Full control over the rules sounds like the opposite of supplier dependency, and it is often sold that way. But these systems carry more interdependence than they appear to from outside: a single option can affect a bill of materials, a price, a part number, a drawing and a lead time at once. Someone editing with good intentions and an incomplete picture can do a lot of damage quickly — and the damage shows up in quotations, not in an error message.
What you want is not maximum freedom but safe change: a defined set of things a trained user can edit directly, anything deeper behind review, the effect of a change visible before it is approved, and a way back. Ask where that line sits and who decides it, rather than whether editing is possible at all.
05
Is every rule change versioned?
A quotation was produced under the rules as they stood at the time. If you cannot reconstruct that version, you cannot explain to a customer why their price was what it was.
06
What happens when a rule change turns out to be wrong?
Ask specifically about rollback. Reverting an update should take minutes and should not require restoring a backup of the whole system.
The scope matters as much as the speed. It should be possible to update — and roll back — a single product series or a single component on its own, without the whole system going through a release. If every correction means a full update, small fixes wait for the next release window, unrelated changes travel along with them, and a mistake in one series forces a rollback of all the others.
Whoever still thinks in large data rollouts will keep postponing them. When every release is big, risky and expensive, the natural response is to make fewer of them — and your configurator falls further behind your actual products with every month that passes.
07
Can a configuration be reproduced exactly, years later?
Each configuration should record the rule version and price basis it was created under. Without that, a stored configuration is only an approximation of what you actually sold.
Part 2 · Questions 8–13
The data
Whether your product data stays yours, stays consistent, and survives the next system.
08
Where does the product data sit — inside the configurator, or outside it?
Data maintained inside the tool becomes an island. Add a second product range and you have two versions of the truth. Held separately, the data serves the configurator, the website, the datasheet and whatever comes next.
09
Is every quantity stored in one unit, with no mixing?
Mixed units within the same quantity, and sizes recorded in more than one notation, look harmless at the moment they are entered and cost you a wrong configuration later. Store one canonical unit per quantity, with the unit declared rather than implied by a column name or a convention someone remembers.
Every conversion then belongs in code or behind an API — one implementation, tested once. A conversion repeated in a rule, in a spreadsheet formula and in a screen field is the same conversion existing in several slightly different versions, and the differences surface as rounding nobody can trace.
This is what makes data neutral: the same figures usable in the configurator, the datasheet, the website and whatever replaces them. Ask it of the data you already hold, not only of the new system.
10
Can you export everything, at any time, without asking?
Rules, configurations, prices, version history. In an open format, on demand. If the answer involves a support request, the data is not really yours.
11
If you introduce a PIM later, what has to change?
Most manufacturers get a PIM eventually. If the configurator holds the master data, introducing one means rebuilding. If the data sits in a neutral layer, the PIM takes over that layer and the configurator never notices.
12
Where do performance curves and other technical datasets live?
A PIM will not hold them. Neither will most configurators. Technical data needs its own home, its own owner and its own update path — ask where that is before you need it.
13
Who maintains the data after go-live, and what does that take?
Ask to see the interface a non-developer would use. If maintaining the data means editing a spreadsheet and sending it to the supplier, you will stop maintaining it.
The flow should be this short: you make the change yourself, push it to a test system, and create a quotation with it straight away. You see the effect on price, part number and documents within minutes — before anything reaches production. If that loop takes days and runs through the supplier, data maintenance turns from a routine into a project.
Part 3 · Questions 14–20
Running it
Storage, servers, failure, load and the phone in a sales engineer’s pocket.
14
What does one stored configuration weigh?
Every quotation you issue needs to be retrievable years later — that part is not negotiable. The question almost nobody asks is how much each one costs to keep. A configuration that carries a geometry model, generated images and an embedded document is orders of magnitude larger than one that carries a set of values, and at any serious quoting volume the difference compounds.
It stays invisible for a long time. Nobody sees the figures in daily use, office documents and screen captures are already far heavier than anyone assumes, and storage is somebody else’s budget line. It surfaces years later, as an IT cost nobody planned for and backups that no longer finish overnight.
Ask for the size of a single stored configuration and the projected growth over three years. A supplier who has thought about it answers in numbers: what is stored once and referenced rather than duplicated, what is regenerated on demand rather than kept, and how geometry and images are compressed.
15
Who provides the infrastructure, and who carries it when it turns out to be too small?
Taking the servers in-house looks cheaper on the day the contract is signed. You think you have saved money. The failure mode is specific. Once the system is live and slower than expected, somebody has to approve more hardware, and that approval competes with everything else in the IT budget. Often it never happens. The cost does not rise — the system simply stays slow, permanently, and everyone adapts to it.
So ask the supplier what the system actually needs to run well: memory, database sizing, how it behaves on the hardware you intend to give it, and at what point that has to grow. A supplier who knows the answer and lets you discover it later has avoided an awkward conversation at your expense.
16
What happens when a server fails?
Ask about redundancy, failover and the actual recovery time — not the backup policy. A daily backup means a bad day costs you a day of work.
If you host it yourself, high availability means at least two of everything — servers, storage, network, power — and people who can respond at any hour. In practice you end up buying hardware that is either too small or, worse, sized far beyond anything the system will ever need, and the investment is enormous for a setup that spends most of its life waiting. Building genuinely highly available hosting in-house is like building your own aircraft to fly to a customer meeting: possible in principle, and not something anyone who does it for a living would recommend.
17
Are development, staging and production kept separate?
Changes tested against live data are changes tested on your customers. Staging is the difference between finding a problem yourself and a customer finding it in a quotation.
Three environments are the working minimum. Development is where rules and data are changed and new functions are built. Staging mirrors production with current data, and it is where the people who own a change check it — with a real quotation, not a screenshot. Production only ever receives what has passed staging, and only for the series or components that actually changed.
Ask whether all three exist, whether staging really holds a current copy of the production data, and how a change moves from one to the next — and back again.
In-house, that means three systems to buy, patch and keep in sync — and in practice, staging is the first one to be cut.
18
How is the system monitored, and who gets told when it breaks?
If the first indication of a fault is a sales person reporting it, the system is not monitored. Ask what is measured, what raises an alert, and who responds outside office hours.
In-house, this gets expensive quickly. Monitoring is only worth something if the person watching can actually fix what they see. An employee who watches a single system, but has neither the access nor the knowledge to intervene, is a cost without a remedy — the alert arrives on time, and the fix still has to wait for someone else.
19
How fast is it under load — and is that speed guaranteed?
Your internal team is not a load test. If customer-facing access is anywhere in the plan, ask what happens when concurrent use is several times higher, and whether anyone has actually measured it rather than estimated it.
Speed is not a detail. A configurator that pauses after every choice is used reluctantly by sales and abandoned by customers — and every second of waiting is multiplied by every option, every quotation and every user, every day. Slow systems do not fail visibly; they simply stop being used, and the old spreadsheet comes back.
Ask for response times in writing: how long a configuration step takes, how long a complete quotation takes, measured under realistic load — and what happens when those figures are missed. A supplier who will not commit to a number has not measured it.
In-house, load capacity is whatever was bought on day one. When demand grows, you are back at question 15, waiting for a hardware approval that may never come.
20
How does it behave on a phone?
Sales work on site, not at a desk. A tool that technically works on mobile but is unusable on mobile gets used after the visit, from memory, and that is where errors come from.
Part 4 · Questions 21–23
Testing and releases
How changes reach production without reaching your customers first.
21
What is tested automatically before a release goes out?
Ask for two things: that rule changes are checked against the full set of existing configurations, and that the application itself is tested end to end. Manual testing does not scale past the first few updates, and it is the first thing to be skipped under pressure.
22
How often can you get a change, and how fast if something is wrong?
A planned release cycle is usually right. But there should be a defined fast path for corrections, agreed in advance rather than improvised the first time it is needed.
23
Can you tell, before approving a rule change, what it will affect?
Running the new rules against every existing configuration and reporting the differences takes seconds for a machine and is impossible by hand. Without it, approving a rule change is an act of faith.
Part 5 · Questions 24–26
Who uses it
Whether the people it was built for will actually use it — and how you would find out if they do not.
24
Who was asked before it was built?
The people who will quote with it every day know where the old process hurts and where the shortcuts are. If they first see the tool at go-live, they will judge it by what it does differently, not by what it does better.
This happens more often than anyone admits. Nobody quite trusts the new configurator, so nobody uses it until they have to — and then it is dropped on the team at the last moment and expected to work from day one. The result is predictable: every gap becomes proof that it was never going to work. That is not a technical problem. It is acceptance, and it is psychology. People defend the tool they helped shape; they resist the one that was done to them.
25
Is it faster than the spreadsheet it replaces?
Sales will not switch to a tool that costs them time, however much better the result is. Ask to time a typical quotation, start to finish, against the way your team does it today. If the new way is slower, the old way survives in parallel.
26
How will you know whether it is actually used?
Ask what usage is measured: quotations created, configurations abandoned, quotes still produced outside the tool. Without those figures, low adoption is invisible until someone asks why the numbers in the CRM do not match.
Part 6 · Questions 27–28
Who sees it
Whether the tool can face a customer, and what it hands to the factory.
27
Could you put this in front of a customer?
Many internal tools never reach customers — not because of policy, but because the interface is too slow, too technical or too ugly to show. If customer access is in your roadmap, judge the tool today by whether you would be comfortable showing it today.
28
What does a configuration give the customer and the factory?
A price and a part number are not enough. Ask what the customer receives to be confident the unit fits, and what production receives to build it — especially for configurations that need a CAD drawing, and whether that drawing is generated with the configuration or still has to be drawn by hand.
Built properly, a configurator pays for itself on both sides. Internally, a calculation that used to take days runs in minutes, and the quotation goes out the same hour — with approved, guaranteed prices, and drawings and bills of materials production can rely on. Fewer manual steps mean far fewer errors, and every error that never happens is a correction, a credit note and an awkward phone call that never have to be made.
For the customer, it changes the experience. Nobody has to call anyone for a first estimate. Every option is open to them, at any hour, with a realistic image of exactly what they are building and a price they can trust. People enjoy building something themselves — and a customer who has put together their own unit, quickly and with confidence, comes back to do it again.
Timeline · From decision to go-live
How long it really takes
From the decision to a configurator your sales team actually quotes with, experience shows a clear pattern.
The difference between the two rows is not the technology. It is how fast decisions are made.
Preparation typically takes six to nine months: collecting and cleaning the product data, agreeing units and rules, deciding who owns what — and settling the questions on this page. Implementation and acceptance take another six to nine months: building, testing against real configurations, and signing off series by series.
Going live in under twelve months is realistic. It requires short decision paths — people on your side who can decide on data, rules and responsibilities within days, not in the next committee cycle. When projects take longer, the cause is rarely the technology. It is decisions that are discussed for months instead of made.
One decision shortens the timeline further. If the system is set up early and handed to sales from the start of implementation — working with each series as soon as it is ready — the separate acceptance phase at the end largely disappears. Sales accepts the system by using it. That alone often saves another three to six months.
Ask yourself before you ask any supplier: who on your side can make those decisions, and how quickly?
Part 7 · All 28 at a glance
The checklist
Tick off what a supplier can show you working — not what they promise. Items marked non-negotiable are the ones we would not sign without; the rest depend on your products and your roadmap.
- The rules
- The data
- Running it
- Testing and releases
- Who uses it
- Who sees it
Ask these questions on us, too.
We build configurators for pumps, tanks, hydraulic products and oak cabinets. These questions come from projects we have delivered and from projects we have been asked to rescue.
We run what we build. Hosting, monitoring, staging and releases are included — not as an add-on, but because the questions above only have good answers when the same team is responsible for the code and for the system it runs on:
- Guaranteed system response times
- Speed your sales team notices on every quotation
- Code optimised for the load it actually carries
- Scaling when demand grows, without waiting for a hardware approval
- Monitoring around the clock, by the people who can fix what they see
If you are evaluating a configurator — ours or anyone else’s — we are happy to go through this list with you against your own products and data.