Custom softwareIntegrationBudgetBusiness software
Custom product configurator: when to build one instead of renting a SaaS tool, and what drives the cost
10 min read

Build a custom product configurator when your compatibility and pricing rules are too rich for an off-the-shelf tool, when the configurator has to produce a quote or an order your ERP can use, or when it is a selling point in its own right. For a catalogue of simple options on an online store, a SaaS configurator is cheaper and faster to launch. The decision rests on business rules and integrations far more than on the interface.
Search for "product configurator" and the first page is mostly vendors selling their own tool, plus a few posts that price a custom build mainly to talk you out of it. This guide takes neither side. It helps you work out which situation you are in.
What counts as a product configurator
A configurator is an application that lets a customer, a sales rep or a dealer build a product from options, blocking impossible combinations and updating the price as choices are made. In practice it covers quite different jobs:
- visual personalisation: colour, material, engraving, on a consumer product sold online;
- technical configuration: dimensions, power ratings, compatible accessories, on industrial products or equipment;
- commercial configuration, usually called CPQ (configure, price, quote): a rep assembles an offer, applies approved discounts and sends a quote for signature;
- manufacturing configuration: the customer's choices become a bill of materials, a routing or a drawing for the shop floor.
SaaS tools handle the first job very well, the third reasonably well, and the last two much less so. That is where custom development comes in.
What SaaS configurators do well
Subscription configurators, usually plugged into an e-commerce platform, have real strengths:
- you can go live without a development project;
- layered images or 3D models, with an editor to prepare them;
- native add-to-cart on the major e-commerce platforms;
- continuous updates paid for by the vendor's whole customer base.
If your product comes down to a dozen independent options, each with a fixed surcharge, start there. You will test demand before investing, and when the tool hits its limits you will know exactly what is missing. The general reasoning is laid out in our build vs buy guide.
Four signs a custom build is justified
Your options are not independent
The heart of a configurator is its rules engine: a given width requires a reinforcement, a given motor rules out a given finish, an accessory only exists above a certain rating. When those rules run into the hundreds, depend on each other, or change with standards, a generic tool forces workarounds: dummy options, warnings instead of hard blocks, manual checks after the order. Every workaround is a wrong order waiting to happen.
Price is calculated, not added up
SaaS configurators handle "base price plus surcharges" well. They struggle with per-metre pricing with breaks, raw materials indexed to market prices, discounts by channel or by dealer, or a minimum margin to enforce. If pricing today runs through a spreadsheet only one person truly understands, that spreadsheet is what the configurator must replace, and that rarely works without development. Our article on replacing a critical spreadsheet with a custom application covers that situation.
The output has to reach the ERP or the shop floor
A configurator that stops at a nice picture means someone retypes the order. The real gain comes when the customer's choices automatically become an item code, a bill of materials, a quote in your own format or a production order. That link depends entirely on your ERP, what it exposes and how your items are coded, which is the subject of our guide to integrating a custom application with an existing ERP.
Several audiences, several sets of rights
The same configurator often serves three audiences: end customers who see list prices, dealers who see net prices and their own discounts, and internal reps who can force an off-catalogue option subject to approval. Those layers of permissions, prices and approvals are hard to model in a tool designed for a web store. A dealer-facing configurator is often close to a custom client portal.
Bad reasons to build
- Wanting nicer 3D than a competitor. 3D is expensive to produce for every variant and does not fix a wrong rule. One good photo per variant often sells just as well.
- Covering the whole catalogue on day one. A configurator that models every product before it has sold the first one is a project heading for overruns.
- Saving the subscription. On a simple catalogue, the subscription will almost always cost less than a build plus hosting and maintenance.
What drives the cost of a custom configurator
Pages quoting a single price usually compare projects that have nothing in common. Cost depends on five blocks, which vary enormously from one company to the next:
| Block | What makes it grow | What keeps it small |
|---|---|---|
| Rules engine | Many interdependent, undocumented rules | Rules kept in a maintained table |
| Pricing | Price breaks, indexed materials, per-channel discounts | One stable price list |
| Visualization | Real-time 3D, renders per variant, augmented reality | A photo or drawing per variant |
| Outputs | Branded quotes, bill of materials, production orders | A summary sent by email |
| Integrations | Legacy ERP without an API, CRM, store, several languages | One system to feed, with a documented API |
Two items are almost always underestimated. First, collecting the rules: they live in an experienced estimator's head, in old quotes and in exceptions nobody wrote down. Second, running the configurator: every new product, price increase and regulatory change touches it. Decide who on your side will maintain rules and prices, and insist on an admin screen that lets them do it without a developer.
For overall budget ranges and the factors behind them, see our guide to custom business application cost. You do not have to pay everything upfront either: a custom build can be financed as a monthly subscription, like a SaaS tool, as compared in subscription vs upfront build.
The hybrid route
Between renting and building everything, a sound option is to keep the storefront on your e-commerce platform and build only what is specific to you: the rules and pricing engine, exposed through an API that the store, the dealer portal and the sales team's tool all call. Each rule then lives in one place, and every channel shows the same price for the same configuration. When a configurator must serve several channels, this is often the most robust design.
Selling to EU consumers: the right of withdrawal
If you sell to consumers at a distance in the European Union, one legal point directly shapes the configurator. The 14-day right of withdrawal does not apply to "goods made to the consumer's specifications or clearly personalised", under Article 16(c) of the Consumer Rights Directive 2011/83/EU. National guidance reads that exception narrowly: France's official public service site, for instance, states that choosing options from a manufacturer's standard range, such as a colour or finish, does not count as personalisation (service-public.gouv.fr, checked 1 January 2026).
In practice, the configurator needs to know which configurations are standard, and therefore returnable, and which are genuinely made to order, and to say so clearly before checkout. Other markets have their own rules. Treat this as a business rule like any other, and get legal advice for your specific case.
Common mistakes
- Starting with the interface. Screens are easy to redo; a wrong rule costs you an order. Rules and pricing come first.
- Hard-coding prices. A price change should be an edit in an admin screen, not a ticket for a developer.
- Forgetting the special request. Reps will always have one. Provide a free-text option with approval, or they will work around the tool.
- Not testing with real quotes. Replay dozens of recent quotes in the configurator and compare prices line by line before launch.
- Not measuring. Without tracking abandoned configurations and quotes that convert, you cannot tell whether the tool sells.
What a first release should cover
A good first release covers one product line end to end: its rules, its pricing, a summary or quote, and a handover to whoever processes the order. A small group of reps or trusted dealers uses it and reports price discrepancies. Other lines, 3D, full ERP integration and public launch follow once that first line has proved itself. It is also the best way to find out whether your rules are complete before committing to the rest.
A grid to decide
| Your situation | Best fit |
|---|---|
| Simple, independent options sold online | SaaS tool on your store |
| Store in place, but pricing or rules beyond the tool | Hybrid: dedicated rules engine |
| Technical product, quote or bill of materials sent to the ERP | Custom configurator |
| Several channels (public, dealers, reps) with different prices | Custom or hybrid |
| Rules not written down anywhere | Document the rules first, choose later |
Where to start
- Gather twenty recent quotes, simple and complex, with the price actually invoiced.
- Have the rules written down by whoever prices orders today: compatibilities, exclusions, price calculation, allowed discounts.
- List the outputs you need: quote, bill of materials, order, and the system that must receive each one.
- Test the closest SaaS tool on your hardest product line. If it holds up, keep it.
- Otherwise, see the flow before you pay. We build a free visual prototype, presented on a video call within 5 business days: your reps configure a product on screen before anything is developed, as explained in see your software before you pay.