Developing an in-house pricing tool: 

the actual cost of a build

Why does the build always seem cheaper at first?

Because, at the outset, that’s exactly what it is. A data team with access to sales history can produce a reliable elasticity model in a matter of weeks and, within a few months, an interface that generates prices. At this point, the comparison with a vendor’s budget is overwhelming, and the choice seems obvious.

The bias stems from the fact that we are comparing, on the one hand, the cost of building a working prototype and, on the other, the price of a system in production. These are not the same things. In between, there is everything that turns a recommendation into a decision implemented on the store shelves, and that is where virtually all the effort lies.

The Success of the Prototype

A prototype that works with a single category creates an unrealistic sense of confidence. It validates the feasibility of the calculation, which has never been the difficult part. It says nothing about how the system will perform with forty thousand SKUs, across twelve store formats, and with thirty users who have different permissions and differing opinions.

It’s also the most rewarding phase of the project—the one where results come quickly. What follows is less spectacular and much longer, which explains why some people drop out: the team shifts from building a model to maintaining a system, and that’s a different line of work.

What a Pricing System Really Includes

Here's what needs to be built, in the order in which the teams discover it—which is rarely the order they had planned.

The Product Catalog

To make a pricing recommendation, you need to know what a product is, which product family it belongs to, which SKUs it replaces, and which internal competitors it faces. In most retail chains, this information exists in multiple locations, in various formats, and is inconsistent. Ensuring the reliability of this foundational data is a project in its own right, which we detail in “Ensuring Data Reliability Before Deploying a Pricing Tool.”

Competitive Matching

This is the component that is most consistently underestimated. Determining whether a competitor’s product reference is actually the same as yours—despite different wording, different packaging, and the absence of a common code—is a difficult problem that cannot be solved simply by matching strings of characters. A mismatch results in the product being aligned with the wrong item, and the consequence is immediately apparent in the margin.

The Rules Engine and Its Governance

An optimization calculation isn't enough: you need a set of rules, priorities among them, exceptions, approval workflows, permissions by profile, and traceability. And you need the mechanisms to prevent this set of rules from becoming obsolete—a topic we address in the section on rule debt in a pricing engine. It’s a comprehensive management application, not a script, and the list of what it must cover aligns with that of the retail pricing software comparison.

Explainability

A buyer does not set a price that he cannot justify. The system must therefore reconstruct, for each recommendation, the path that led to it: what data, what elasticity, what rule, what trade-off. Building this traceability after the fact is much more costly than having it in place from the start, and yet that is almost always what happens.

Compliance

Break-even thresholds, promotional guidelines, reference prices, and industry-specific requirements: these rules are not optional; they are constantly evolving, and a mistake can have consequences that go beyond sales. Implementing them is feasible; however, adhering to them over the long term requires ongoing monitoring that few in-house teams are able to organize.

What the Numbers Say About Internal Developments

The most revealing figure in this study isn’t the dropout rate; it’s the gap between plans and actual results: 8% of projects were delivered on time, and 11% were delivered within budget. This does not mean that internal teams are less competent. It means that an internal tool is evaluated against an estimate made at a time when the least was known, and that it never takes priority over a business emergency.

The Mechanism of Abandonment

It almost always follows the same pattern. The project delivers a first usable version; it serves its purpose, and adoption grows. Then requests for changes pile up faster than the team can handle them, because the team also has other tasks to attend to. Processing times get longer, users start working on other things again, usage declines, and the issue of maintenance eventually comes before a committee that notes low usage.

Therefore, abandoning a project is not a technical failure. It is a consequence of the fact that an internal tool is in constant competition with the other priorities of the team responsible for it.

The Cost No One Budgets For: Business Continuity

In practice, an in-house pricing tool relies on two or three people. They are familiar with the architectural choices, special cases, and the reasons for exceptions. This knowledge is rarely documented, because they are available and it’s faster to just ask them.

On the day they leave, the company discovers that it has a system it no longer knows how to modify. It then enters a well-defined phase: it leaves the system alone, works around it, and eventually rebuilds it. The cost of this process does not appear in any of the initial arbitration files, and it generally exceeds the price difference that had motivated the decision to build in the first place.

The Three Questions That Reveal the Risk

• How many people can modify a rule in the engine without the author's help? If the answer is one or two, the asset is fragile.
• How long does it take for a newcomer to become self-sufficient with it? After a few weeks, the knowledge isn't in the code—it's in people's heads.
• What happens if a regulatory requirement changes in three months? The question isn't whether it's feasible, but who will do it and what it will replace.

Time Before Value

There is one final factor that is almost always missing from the comparison: time. While the solution is being built, pricing continues to be managed as before. If a solution can increase margins by +0.5 to +3 points in a few months, and in-house development takes eighteen months to reach an equivalent level, the cost of the delay adds up—and it often exceeds the savings on licensing fees.

When a Build Is Still the Right Choice

There are cases where building is the right decision, and it is helpful to identify them specifically rather than automatically suggesting a purchase.

• A narrow, stable scope. A pricing structure tailored to your industry, covering a few hundred SKUs, that doesn't change every quarter: that's a good candidate.
• A real competitive advantage. If your pricing strategy is, in itself, a differentiator that no one else uses, it won't be off the shelf.
• As a complement, not a replacement. The approach that works best combines a platform for the foundation—namely, the reference framework, matching, rules, compliance, and traceability—with in-house development for the specific layer that sets you apart.

The Decision-Making Criterion, in One Question

The right question isn't “Are we capable of building it?” The answer is almost always yes, and it doesn’t tell us anything. The right question is:Are we capable of maintaining it for ten years, despite staff turnover, shifting priorities, and regulatory changes? It is this second criterion that accounts for the 71% failure rate, and it is this that must be evaluated before making a decision.

Finally, a useful distinction: this article discusses the development of a tool by an in-house data team. The related question—whether to use general-purpose AI instead of a specialized solution—is a separate topic, which we cover in “General-Purpose AI vs. Specialized Pricing Solutions.”

FAQ