RevOps Review
Articles

Why Nue never built a pricing rules engine

Why Nue never built a pricing rules engine

Why Nue never built a pricing rules engine

Tina Kung, CTO, Nue

Tina Kung, CTO, Nue

Copy to clipboard

Every time you add a new pricing rule, you add a risk. You may not realize it until something breaks, and by then, the damage is done. 

 

New tiers, bundles, and pricing models are accumulating faster than ever. With them comes a growing network of interdependent rules, each one a variable nobody fully tracks. It’s a problem that any team experimenting with packaging or managing hybrid pricing models will eventually have to reckon with. 

 

If you’re moving fast, the pricing rules built to support you become the thing holding you back. A change that should take a day triggers a cascade of other changes. Pricing, one of the sharpest levers a revenue team has, becomes something nobody wants to touch. 

 

I spent years inside Salesforce and Zuora watching rules engines run up against their own complexity. That’s why when we founded Nue, we made a decision others never considered: we did not build a pricing rules engine. As AI makes code generation a commodity, that decision matters now more than ever. 

Every rules engine will eventually fail

But when you layer conditional logic on top of point-and-click configuration, rules start triggering other rules in ways nobody can fully track, and the result is a brittle system. Adding a smarter interface on top of that doesn’t help; it accelerates the debt. 

 

So we built Nue differently, using a unified object model where pricing, quoting, billing, and revenue recognition share one source of truth. Structural pricing primitives like price tags, multi-attribute pricing, and product relationships sit on top, so the complexity lives in the pricing model itself, not in a chain of conditional logic that can break under pressure. The architecture carries the weight that rules used to carry, in a form you can inspect, govern, and change. 

 

That foundation ultimately is what made Nue’s Price Builder Chatbot possible. The barrier to building pricing rules is gone, and what matters is whether the architecture underneath can safely host and govern what AI generates. The AI isn’t working around a fragile rules engine; it’s operating on a system designed to be governed. 

AI can’t fix broken infrastructure

The Price Builder Chatbot lets revenue and pricing teams describe logic in plain language and translates it into executable pricing rules. The point-and-click, no-code promise that defined CPQ for a decade is no longer a differentiator. AI can do that now. What matters is the architecture underneath.

 

Because the architecture is built to be governed, the AI can do more than just generate rules. It can tell you what your dozens of active pricing rules are actually doing, in plain language. It catches the cyclic loops, the conflicts, the rules firing in sequences that nobody intended.

 

Understanding your own pricing engine used to require the engineer who built it. Now it doesn’t. 

 

Pricing rules that used to take days to build and weeks to validate can be launched in minutes. And when something needs to change, you can change it without worrying about what it might break.

Encode it once, rely on it everywhere

Building pricing faster is an obvious win. Trusting what you built matters even more.

 

I saw this often inside legacy CPQ systems. A pricing rule was built correctly for direct sales, but when the same deal closes through a partner or self-service channel, the same discount wouldn’t apply. The rule wasn’t wrong, but because it didn’t run everywhere it was supposed to, everyone spent time reconciling something that should have been automatic. 

 

With Price Builder Chatbot, the rules you define run consistently across every channel not because there’s someone checking, but because the architecture enforces it. The AI audits your full rules library, detects conflicts before they reach a quote, and gives finance visibility into exactly what the pricing engine is doing and why. 

 

For most teams, pricing experimentation and pricing control have always been at odds. Move fast and you risk margin; lock things down and you lose agility. But this tension is a product of rules-based architecture, not an inherent trade-off. 

 

When governance is structural rather than procedural, you don’t have to choose. 

The future of pricing isn’t more rules

Pricing has always been one of the highest-leverage decisions a revenue team can make. What erodes that leverage isn’t the complexity of pricing itself, it’s the complexity of the systems built to manage it. 

 

I've seen what happens when pricing infrastructure can't keep pace with the business. It doesn't just slow teams down. Pricing stops being a lever and starts being a liability.

 

When the architecture is designed for governance, that changes. Pricing becomes something you can move on quickly, trust completely, and hand off without it falling apart. 

Takeaways

Most pricing problems are actually architecture problems in disguise. Here’s what changes with Nue’s Price Builder Chatbot: 

  • Every pricing rule added to a system is also a risk. Price Builder Chatbot generates, tests, and audits rules in plain language with no coding or manual maintenance required.
  • Governance is encoded into the system, not left to process or memory. Rules run consistently across every channel, every time, without anyone having to check.
  • When governance is structural, not procedural, pricing agility and pricing control can coexist. 

With the right architecture, pricing becomes something you can act on quickly, trust completely, and hand off without losing institutional knowledge.