Context

Pricing systems often rot in a very specific way: the business keeps changing, but the pricing logic stays trapped in code paths that only engineers feel safe touching.

In this quoting platform, extra charges depended on things like mode, direction, incoterms, client expectations, and workflow type. That was manageable when the rules were few. It became painful once the business needed those rules to evolve quickly without turning every change into a deployment, a code review, and a fresh round of regression anxiety.

The real opportunity was not just “write cleaner pricing code.” It was turning operational policy into software the business could actually manage.

Problem

The old pattern had predictable downsides:

  • charge logic was embedded too close to UI and request-handling code
  • similar rules had to be re-implemented across multiple quote flows
  • ordering and precedence were hard to reason about
  • small policy changes carried disproportionate delivery risk
  • non-engineers had no safe way to own rule maintenance

That slowed down both product delivery and day-to-day operations.

Constraints

This could not become a pure platform rewrite.

  • Existing quote flows already mattered to revenue teams.
  • Standard and multi-lane workflows both needed support.
  • Historical data shapes could not be broken casually.
  • Admin tooling had to be understandable to non-engineers.
  • Rule updates needed safe persistence and rollback behavior.

The answer had to improve flexibility without making pricing behavior more mysterious.

What I Built

I pushed the pricing logic toward a config-driven model with explicit rule definitions and reusable behavior.

First, I separated rule definition from UI handling. Instead of scattering conditional pricing behavior across form code, I centralized the rule logic in a dedicated engine that could evaluate charge conditions consistently. That created one place to reason about how auto-charges should be applied.

Second, I created admin-managed rule configuration. I used a shared form configuration model so the rule editor itself could be driven by structured metadata instead of hand-built, one-off forms. That let the system support different rule shapes without turning the admin surface into a maintenance trap.

Third, I made ordering and precedence explicit. Charge rules are not just about whether something applies. They are also about when it applies and how conflicts resolve. Drag-and-drop ordering and clearer persistence rules gave operations teams a safer way to control behavior without diving into code.

Fourth, I designed for more than one quote workflow. A good rules system should not collapse the differences between standard and complex quote types, but it should avoid duplicating logic where the policy is actually shared. I kept the workflow distinctions where they mattered and reused the rule engine where they did not.

Fifth, I treated persistence like real operational state. Save, edit, duplicate, and delete behavior ran through controlled persistence paths instead of casual mutations. That mattered because the consequences were real: the next quote a salesperson generated might depend on those rules immediately.

Validation

Validation had to cover both technical correctness and operator confidence.

I checked rule behavior against known quoting scenarios:

  • different modes and directions
  • incoterm-dependent charge cases
  • legacy-shaped records that still needed to behave correctly
  • rule reordering and duplicate/edit flows
  • standard and multi-lane quote types

I also treated admin usability as part of validation. If the people responsible for pricing policy could not predict what the system would do after a change, the design was not done.

Outcome

The result was a more adaptable pricing platform.

  • Pricing policy became easier to evolve without risky code changes.
  • Shared behavior stopped drifting across quote workflows.
  • Rule maintenance moved closer to the people who understood the policy best.
  • Engineers spent less time on small operational changes and more time on higher-leverage work.

What makes this page useful beyond logistics is the pattern itself. Many teams have business rules hiding in controllers, forms, or one-off scripts. Moving those rules into admin-managed configuration is often the difference between a system that scales operationally and one that creates permanent delivery drag.

Lessons

The most important lesson was that “config-driven” only helps if the behavior becomes clearer, not looser.

Poor configuration systems replace hardcoded logic with chaos. Good ones make policy explicit, controlled, and easier to validate. That means naming matters. Ordering matters. Persistence rules matter. Admin UX matters.

If those parts are weak, the system becomes flexible in all the wrong ways.

If you have business rules stuck in code and every policy change feels bigger than it should, that is exactly the kind of system untangling I like. Let’s talk .