Series
Pricing Engineering
Building the engine, not the strategy. Fourteen posts on the systems beneath pricing decisions — rule models, evaluation pipelines, testing, explainability, shadow mode, replay-based simulation, and the architectural seams that keep a pricing platform operable as it grows. Lessons from production work in a closed stack; patterns extracted into the open as bre-go and traffic-gen.
14 posts in total
Posts in this series, in order
What Is a Business Rule?
A markup of 3% looks the same in code and in config — until somebody has to explain who changed it, when, and why.
Designing a Rule Model
The Rule struct is the contract between business intent and runtime execution. Get the contract wrong and every other layer pays for it.
Rules as Data, Not Code
Moving rules into YAML is the easy part. Making the loader trustworthy is where the work is.
Matching Rules at Scale
Most rule engine bugs are not in the actions. They are in the way the engine decided which rule was supposed to fire.
Building a Rule Evaluation Engine
An engine that runs in one opaque step is an engine you cannot debug. Make the stages explicit and the bugs have nowhere to hide.
Testing Business Rules
Tests that pin the engine's internals will rot. Tests that pin the business behaviour will outlive every refactor you ship.
Explainable Rule Execution
A pricing system that cannot explain a decision cannot be safely operated. The explanation is not a debug aid. It is the system's contract with everyone who has to trust it.
Generating Synthetic Pricing Traffic
Synthetic traffic is not fake data. It is controlled pressure on assumptions your production data cannot, by definition, exercise.
Shadow Mode for Pricing Systems
Shadow mode lets new logic be wrong in production, on production traffic, before a single customer pays for the bug.
Replay-Based Simulation
Replay turns pricing discussions from opinions into observable differences. I haven't built the lab yet. This is the shape I have been studying.
Rule Engines vs Decision Engines
A rule engine answers what matches. A decision engine answers what should happen. The gap between those two questions is where most pricing platforms grow up.
Building Pricing Systems That Age Well
The maintenance work is real. We have been doing it by hand. This post is the shape of pushing it into the decision engine so the year-three operator does not depend on the year-one engineer remembering.
Ten Mistakes I Made Building Pricing Platforms
The expensive mistakes are never about syntax. They are about boundaries, behaviour, and ownership — the parts that look fine until they don't.
What I Would Build Differently Today
The best pricing systems are not the most sophisticated. They are the ones the team can understand, test, explain, and change safely.