The first time I watched a dynamic-pricing job touch a live catalog, the algorithm was the part I trusted. The part that scared me was that nothing stood between its output and three thousand real product prices. A stale feed, an off-by-one in a margin floor, and the system would happily write all of it to the storefront. The pricing math was sound. The architecture was a loaded gun.
That is the real problem with dynamic pricing, and most tutorials get it backward. Proposing a price is the easy ten percent. Keeping a pricing engine from doing damage on a real catalog is the other ninety, and it is an architecture question, not a modeling one.
Here is the structure I now build every pricing system around. Four layers, and each one can only do its own job.
The engine proposes. It reads demand and inventory pressure and emits a suggested price. It has no authority to write anything. The part that matters: it takes its constraints as constructor inputs, the margin floor, the ceiling, the maximum step per cycle, and it is built so a suggestion that violates them is not reachable. No try/except catches a breach, because no breach can be constructed. If the floor is $40, the engine cannot emit $38. The guardrail is the type, not a check that runs and hopes.
The merchant policy gates. A proposed price is not an applied price. The policy layer decides: auto-apply inside a narrow window, hold for a human, or reject. This is where the business keeps its hand on the wheel. An aggressive engine behind a conservative policy is a safe system. The reverse is the one that ends up on the news.
The Shopify client executes, and only an approved change reaches the Admin API. The execution layer has no opinion about price. It writes what the gate approved, with real HMAC verification on the webhook coming back, and nothing else. Authority to compute and authority to write are different jobs held by different code.
The audit trail records, and this is the layer people skip and later regret. Every proposal, every gate decision, every write, appended and immutable, each entry carrying a sha256 receipt chained to the one before it. The audit trail is not compliance theater. It is the rollback substrate. At 2am, "roll back four steps" is only a real sentence if every step was recorded, and the rollback itself gets audited too.
Two more invariants earn their place fast.
Fail closed. Stale data or a missing guardrail input freezes actuation. The system never guesses a price to keep moving. A pricing engine that guesses under uncertainty is the one that prices a $400 item at $4 and learns about it from a customer.
No holdout, no lift claim. This is the invariant that separates honest pricing work from a story. If you change prices and revenue goes up, you have learned nothing until you held a control group back. Attribution has to refuse to return a number without an observed holdout. Otherwise you are measuring the season and calling it your engine.
I packaged this two ways, because two different people need two different things.
If you want the architecture to start from, the Shopify Dynamic Pricing Skeleton is the base: FastAPI, Celery, Postgres, Redis, the guardrail engine, the policy gate, the append-only audit trail, fifteen backend tests green, and an honest TECHNICAL_DEBT.md that names every stub and its exact cutover steps. It is a skeleton on purpose. You get a safe, well-shaped foundation and a clear path to production, not a black box that works until it does not. Twenty-nine dollars, full source: https://m87studio.gumroad.com/l/shopify-pricing-skeleton/DEVTO10
If you need to run an actual pilot and prove the lift, Slipstream is the engine: the shadow to canary to live ladder, a kill switch, holdout attribution that will not return a number without a control, and a field playbook for running a fourteen-day pilot from first call to measured result. It runs entirely on a built-in simulator with zero secrets, so you can watch the whole loop before you point it at live revenue. Ninety-nine dollars: https://m87studio.gumroad.com/l/slipstream-operator-kit/DEVTO10
Build the price last. Build the layers that contain it first.
Top comments (0)