Ready-made Configurator vs. Custom Development: What to Check Before Choosing

By Artem Korsakov · 18 October 2026

When a company decides that order calculation needs to be organized, two options are usually discussed: buying a ready-made configurator or ordering custom development. There is also a third option: modify the accounting system in which you already manage your nomenclature and production. Each path has its strengths and risks. The choice depends on how complex your rules are and how roles are structured.

What the options have in common

All three paths require the same preparatory effort. Someone must document the selection rules: parameters, dependencies, prohibitions, and exceptions. Neither a ready-made system nor a developer will know them on their own. If the company is not prepared to assign an engineer to this work, none of the options will yield results.

Therefore, a sensible order is as follows: first, list the rules for one product line, then make a choice. The documentation will become a technical specification for any option and material for comparison.

Ready-made configuration system

Specialized systems are built around a constraint model. For example, Tacton describes how it handles complex product configurations through rules that specify allowable combinations. The strength of this path is that the mechanism for handling constraints is already implemented. You will still need to describe and verify your company's specific business rules.

Questions to ask before making a choice:

• Will your rules fit into the system model without workarounds;
• Who will maintain the rules after launch: your engineer or a contractor;
• How is the exchange with your accounting system structured and who handles it;
• Can roles be configured to match your workflow: manager, engineer, executive, client;
• What is the language of the interface and documentation for your employees.

We do not compare prices and licensing terms here: they must be requested from suppliers based on your volume.

Accounting system modification

If nomenclature and production are already managed in an accounting system, such as 1C (a Russian accounting and ERP platform) for production management or the production section of MoySklad (a Russian inventory-management service), rules can be placed alongside them. If the rules operate within the same database, no separate synchronization of these reference books is required.

Constraints are also clear. Accounting systems are designed for accounting, not for customer dialogue. A questionnaire in the client's language, exceptions resolved by an engineer, and quotation versions for confirmation usually require significant modification. The more complex the rules, the more code must be written and maintained in an environment not designed for this purpose.

Custom development

Custom systems are justified when the process differs significantly from what is built into ready-made products. For example, if external dealers with their own discount levels participate in the chain, the client confirms quotations directly in a personal portal, and exceptions require multiple approvals.

The risks are also real. The rule model must be designed from scratch. You need a contractor who will remain on support, or your own team. Without a good documentation of rules, development will be delayed because requirements will emerge during the process.

Selection criteria

Let us summarize the comparison in a table. It should be filled out with your own data: general impressions here are of little help.

Подпись: Evaluations based on the description of options in the article. For your own company, fill out the comparison using your actual rules.

What no option will solve

Neither a ready-made system nor custom development will fix contradictions within the rules themselves. If two engineers answer differently about an allowable combination, the system will enforce one of those opinions, and the dispute will move to configuration discussions. Such discrepancies should be identified and resolved during the documentation phase.

Also, no option eliminates maintenance. Production releases new versions, suppliers change component lines, and price lists are updated. Someone must make these changes to the rules, and this work must have an owner with allocated time. If there is no such owner, within a few months managers will start asking the engineer again because they will stop trusting the system.

Finally, no option replaces engineering responsibility. The configurator checks the composition based on recorded rules, but for non-standard solutions, the engineer remains responsible, and their decision must be visible in the quotation history.

Pre-decision verification

Before making a choice, it is useful to conduct a brief check using real data:

1. Select ten recent quotations of varying complexity.
2. Document the rules for them in a unified format.
3. Ask each candidate to show how the three most complex rules and one exception will look.
4. Ask what happens if a client changes a parameter after an exception is approved.
5. Compare the answers with how your engineer works currently.

This check takes less time than fixing a poor choice and honestly shows where each option hits its limits.

In the demo scenario, you can trace the general chain that should be required from any option: incompatible items are not assembled, exceptions are resolved by an engineer, and the client confirms a specific version of the quotation.

View scenario

Related article: Why order calculation gets stuck between manager and engineer.

Sources and example boundaries

• Constraint-based configuration
• Production management
• Production

Sources confirm the described functions of ready-made products, not demand or return on investment for custom development. Scenarios and amounts are educational. Demonstrations work with fictional data; real integrations, AI, payments, and external publication are not connected.