A pricing-system overhaul discovered by testing it

Context

A pricing-system overhaul on the ERP side had been in preparation for several weeks, aiming to simplify a historically fragile mechanism: on a product with several variants (sizes, colors…), the old system shared a single "base" price field across all variants, each one being only an offset from that base price. A badly sequenced update on a single variant could silently shift the price of all the others.

What was discovered

While building the price-update app, a real field test revealed that the expected overhaul was in fact already deployed in production — without it having been formally confirmed. The new system now stores a sale price genuinely specific to each variant, which structurally removes the risk of contamination between variants of the same product.

The detection happened by comparing, on real products, the value expected after an update and the value actually synced on the merchant site: a gap appeared, revealing the app was still writing to the old mechanism, now disconnected. The app's code was fixed to write directly to the new field, in line with the price-consistency constraint imposed by the new system. The matter was also escalated to the technical provider in charge of the ERP, with a broader angle: this pattern (automatic price matching, with human guardrails) could interest other of their clients facing the same need.

What was hard

Detecting an architecture change that hadn't been officially communicated as "in production" — the only way to know for sure was to compare the real behavior of the price fields on production data, not to trust the existing documentation.

Stack

ERP (read / write via API), comparative verification on real data.

What this illustrates

A system's documentation can lag behind its real state. Testing in real conditions — even for a simple operational task like a price update — remains the most reliable way to check what a system actually does, rather than what you think it does.