DEV Community

Cn
Cn

Posted on

When a Price Change Doesn't Actually Change the Price Everywhere

The setup

A small content business (online courses, individually priced + bundle pricing) cut its bundle price a few weeks back. The main sales pages were updated correctly — price field, checkout, everything downstream of the "official" product record was consistent.

But this business also runs a secondary content channel: dozens of SEO-oriented blog posts that link back to the main product, each with its own call-to-action line quoting the price. Standard content-marketing setup — write once, publish, let it sit and collect search traffic for months.

Nobody re-checks old posts when a price changes. Why would you? The price is "the price," defined once in the product system. The blog posts just reference it.

What was actually happening

18 days after the price cut, 7 separate blog posts were still quoting the old, higher bundle price in their CTA text. Not because anyone made a mistake — the posts were correct when they were written. They just never got touched again after the price changed elsewhere.

This is the less dramatic sibling of the "bundle contains almost nothing" bug I wrote about last time. No broken checkout, no angry customer emails (it was a price decrease, so if anything readers were mildly undersold). But it's the same underlying failure mode: content and pricing live in different systems, edited independently, with no mechanism forcing them to agree.

The more interesting failure mode — and the one that should actually worry you — is the reverse: a price increase that old posts don't reflect. Now a reader clicks through expecting one price and sees another at checkout. That's a trust problem, not just a stale-number problem.

Why this scales badly

One post with a wrong price is a typo. Seven posts with the same wrong price, discovered weeks later, is a pattern — and the pattern gets worse as content volume grows. Every additional blog post is another place a price can silently go stale. Nobody manually re-audits 20+ published posts every time a price changes; the audit cost grows linearly with content volume while nobody's incentive to actually do it does.

How I found it

Same approach as before: don't trust the rendering, diff the data.

grep -n "¥[0-9,]*" *.html | grep -v "¥300\|¥800\|¥1,200\|¥2,480"
Enter fullscreen mode Exit fullscreen mode

A one-line grep across every locally-saved post, filtered against the list of currently-valid prices. Anything left over is a stale number. Took under a minute to run, and immediately surfaced 7 hits across a content library that would take an hour to eyeball manually — and eyeballing is exactly the kind of check humans are bad at, because every individual post looks fine in isolation. The mismatch only shows up when you compare across posts, and nobody does that by default.

The fix

Once flagged, the fix itself is boring — open each post's editor, swap the old price string for the current one, republish. The interesting part isn't the fix, it's that the check needs to exist at all, and it needs to run every time pricing changes, not just once.

If you're editing prices in one place and referencing them in another (blog posts, email templates, landing pages, changelogs — anywhere text repeats a number that lives elsewhere), that reference will drift eventually. The only question is whether you find out from a customer or from a grep.

The takeaway

This is the same poka-yoke principle as last time, just applied at a different scale: the failure isn't in any single piece of content, it's in the absence of a step that reconciles distributed copies of the same fact. Single source of truth is the textbook answer, but most small content operations don't have the infrastructure for that — so the practical fallback is a periodic diff: pull every place a number is repeated, compare it against the current source of truth, flag mismatches.

It's not sophisticated. It just has to actually run.

If you're maintaining more than a handful of content pieces that reference pricing, and haven't checked lately — it's worth five minutes with grep.

Top comments (0)