Build or buy
Who will be able to change a pricing rule three years from now?
In both scenarios, your trade's rules end up locked somewhere nobody in your company can touch. Inside a vendor's engine, or inside the code of a developer who has left.
Send us one of your quotesWhat fails when you buy
What fails when you buy
The rules engine does not model your trade. That is the most constant complaint from users of generic configurators, at the big vendors as much as anywhere else. Your mark-up rule based on thickness and bend length does not fit the frame provided. You work around it with a free-text field, and the rule goes back into Excel.
ERP integration is handled too late. That is the best documented cause of failure. It gets pushed to the end because it is thankless work, and it derails the schedule exactly when the budget is already burnt.
The salesperson goes back into Excel. If the tool is slower than what it replaces, it loses. Always. No management directive survives three weeks of a tight quarter.
The licence invoice is not the invoice. Implementation cost commonly runs two to three times the annual licence.
An order of magnitude put forward by integrators, who have an interest in saying so. Worth checking with two vendors rather than taking on trust.
And the product can stop evolving under you. Salesforce CPQ has been in end-of-sale since March 2025: existing customers keep their support and their critical fixes, and Salesforce has announced no end-of-life date nor forced any migration. But the innovation is elsewhere, and one day the migration decides itself. It happens to the biggest too.
What fails in-house
What fails when you build in-house
For two years now, the argument has changed. It is no longer "we have a developer", it is "we will build it ourselves with AI".
And that is true: you can produce a convincing prototype in a few days. The demo impresses. The problem does not show up there.
It shows up in the third month. When you have to change a rule written two months earlier, in code nobody reviewed. This is not an impression: three research teams measured it independently, across four published findings, and none of them points the other way.
And it shows up on the day of departure. Whoever built the thing changes jobs. The rules are in their head and in their code. You have just replaced a dependency on Excel with a dependency on a person, with an extra layer of complexity on top.
This is not an argument against AI. We build with it every day. It is an argument against AI with no factory around it.
What others have measured
Four published measurements, and they all point the same way
45%
of generated code contains an OWASP top 10 flaw
Veracode · July 2025
×8
as many duplicated code blocks in one year, five lines or more
GitClear · 2024
+322%
rise in privilege escalation paths on enterprise repositories
Apiiro · Dec. 2024 – June 2025
+153%
rise in design flaws on the same repositories
Apiiro · Dec. 2024 – June 2025
Figures current as of 2 September 2026.
The third way
Three conditions, and they are not negotiable
01
The rules live outside the code.
Your price lists, your compatibilities, your approval thresholds are data you edit in an editor, not lines of program. Your analyst changes a material mark-up without calling anyone.
02
The repository and the data are yours.
No proprietary licence in the stack. The day you leave, we hand you the code and a full copy of your database. That is settled.
03
Maintenance is a contract, not a hope.
Written down, with a scope, a response time and a price. Not "we will be there".
Someone builds it for you, on a base already proven with others, under three non-negotiable conditions.
The three options, side by side
The honest table
| Buy off the market | Build in-house | Have it built on a base | |
|---|---|---|---|
| Getting started | Fast if your trade fits the frame. Slow if it does not. | Prototype very fast. Production, far less so. | In between. The base is done, your trade is not. |
| Who changes a pricing rule | A trained administrator, within the engine's limits. | The developer who wrote it. Nobody else. | Your analyst, in a rules editor. |
| If the vendor drops the product | Re-implementation. It has happened to the biggest. | Not applicable. | Not applicable. No vendor above you. |
| If your developer leaves | Not applicable. | The main risk, and an underestimated one. | The code is documented, tested and picked up by a team. |
| Who owns the code | The vendor. You rent. | You do. | You do. |
| Where your data lives | Wherever the vendor puts it. | With you. | Wherever you decide. Quebec hosting by default. |
| How you get out | An export in a format to be negotiated. | You are already out. | The repository and a full copy of the database. |
Our limits
When it is not us, we say so
Buy off the market if your product fits a stable option catalogue, if your rules look like your industry's, and if you accept adapting your way of working slightly to the engine. It will be cheaper and faster. We can even help you choose it and get it adopted, without building it.
Build in-house if you already have a development team, and if the configurator is the heart of your product rather than a sales tool. Keep it with you, and come to us for the gates to put around it instead.
Talk to us if your trade fits no standard engine, you have no development team, and the quote is what wins or loses you contracts.
We can settle this in one conversation
Send us a real quote. In many cases, looking at it is enough to know which side you fall on.
Your quote is only ever used to build your example. Never shown to a third party, never cited as a reference without your written consent.