DEV Community: Cn

The API Update That Quietly Made a Paid Product Free

Cn — Thu, 06 Aug 2026 02:05:00 +0000

The setup

A content platform I was updating had a familiar-looking editor: write your post, mark a line as "everything above this is free preview," publish. Readers see the free part; paying customers see the rest. Standard paywall pattern, nothing exotic.

I needed to fix a batch of stale price references across several paid posts — pure text edits, nothing structural. Doing it by hand through the rich-text editor for a dozen posts is slow and error-prone, so I pulled each post's content through the platform's API, did the string replacement in code, and pushed the updated body back through the same API.

Fast, clean, verifiable diff before and after. Or so I thought.

What was actually happening

The paywall boundary — "everything above this line is free" — isn't stored as part of the post body text. It's separate state, and the editor UI renders it as a marker positioned within the content. When I pushed a full-body replacement through the API, that marker didn't travel with it. On the next visit to the editor, the paywall boundary had silently reset to right after the first paragraph.

For most of the posts, "right after the first paragraph" happened to be close enough to correct that nothing looked obviously wrong in the editor's own preview — which, critically, is rendered from the account owner's session. Owners can always see the full content, paid or not. The editor's preview will never show you what a non-paying visitor actually sees.

For the posts where the intended free preview was substantial — several paragraphs of sample questions before the paywall — the reset boundary would have made almost the entire paid product readable for free the moment I hit publish.

Why this is the dangerous kind of bug

Nothing about the update looked wrong. The text I changed was correct. The editor's own preview looked correct, because the editor's preview is authenticated as me. The only way to see the actual bug was to load the page with no session at all and see where the content actually cut off for a stranger.

This is the same shape as the bundle-pricing bug I wrote about before: a piece of state that looks like it belongs to the content actually lives in a separate system, edited through a separate path, and nothing forces the two to stay in sync. Except this time the blast radius wasn't "a customer sees an outdated number" — it was "a paid product becomes free and nobody notices until revenue quietly drops."

How I caught it

Same rule as always: don't trust the rendering, check the actual output.

curl -s "<public-post-url>" -H "User-Agent: Mozilla/5.0" | grep -o "Question [0-9]*"

A plain anonymous HTTP fetch, no login, filtered for a marker that only appears past a certain point in each post. Compare that against what should be visible for free. For three posts, content that should have cut off after item 5 was fully readable straight through to item 20.

The account-owner preview inside the editor would never have shown this. It took an explicitly logged-out check to surface it — and that's the part worth internalizing: if a permission boundary exists, the only preview that actually validates it is one taken from outside that boundary.

The fix

Once caught, fixing it was mechanical: reopen each affected post's paywall settings, drag the boundary marker back to its intended position, republish, re-verify with the same anonymous curl check. Nothing clever about the fix. The value was entirely in catching it before a reader did.

Going forward, any workflow that updates paid content through an API now has a mandatory step: after publishing, re-fetch the public URL with no auth and confirm the paid section is actually gated. Not a one-time check — a step baked into the process, every time, because the failure mode is silent and the API makes it trivially repeatable.

The takeaway

APIs are usually the more trustworthy path — no flaky UI, no accidental clicks, a clean diff of what changed. But an API only guarantees the fields it explicitly manages. Anything the UI quietly maintains alongside the content — access boundaries, ordering, visibility flags, anything that isn't literally "the text" — can be invisible to that API and get reset the moment you bypass the UI that was implicitly protecting it.

If you're editing paid or access-controlled content through anything other than the exact UI flow it was designed for, the question isn't "did my edit apply correctly." It's "what else does that UI silently manage that my edit didn't know to preserve" — and the only way to answer that is to check from outside the account that's editing it.

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

Cn — Mon, 27 Jul 2026 05:01:53 +0000

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"

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.

Poka-yoke for your online store: finding the bug that made a "bundle" contain almost nothing

Cn — Thu, 09 Jul 2026 02:27:36 +0000

Poka-yoke, briefly

Poka-yoke (ポカヨケ) is a term from Japanese manufacturing — mistake-proofing. It's not about detecting defects after the fact; it's about designing a check so an error can't slip through unnoticed in the first place. Toyota built an entire quality system around this idea: assume mistakes will happen, and put a mechanism in place that catches them automatically instead of relying on someone noticing.

The same idea applies directly to content and e-commerce platforms — just applied to data instead of physical parts.

Background

Content platforms (think Substack, Gumroad, or any CMS where pricing and bundling are edited separately from the article body) let creators edit price, body text, and bundle membership independently. After enough edits — a price cut here, a bundle reshuffle there — it's easy to end up with a page that looks fine but is quietly broken underneath.

Two real patterns I ran into:

A "bundle" product page rendered normally, but the actual bundle had lost almost all of its member items along the way.
After an individual item's price was cut, the bundle's price wasn't updated — so buying the bundle ended up costing more than buying the items separately, while the copy still said "bundle and save."

Neither of these throws an error. The rendering layer just displays whatever data exists, correct or not. There was no poka-yoke in place — nothing designed to catch the mistake automatically, so it just sat there silently costing money.

What I did

1. Pull the real data via the public API

Most of these platforms expose a read API for published content. If you're logged in, you can usually just fetch with credentials: 'include' and reuse your browser session.

const r = await fetch(`https://example.com/api/v3/notes/${key}?draft=false`, {
  credentials: 'include'
});
const data = await r.json();

2. Cross-check "price mentioned in body" against "actual price"

A simple regex over the body HTML surfaces every price string. Compare that against the real price field (or the actual bundle price) and any mismatch is a stale number left over from a previous edit.

const prices = [...new Set(
  [...body.matchAll(/[\$¥][\d,]+/g)].map(m => m[0])
)];

3. Count actual bundle members vs. the claimed count

Open the bundle page and count how many items are actually attached. Compare it against what the marketing copy claims ("5-piece bundle," etc.). Mismatches here are silent revenue leaks — a customer paying for a "bundle" that's mostly empty is not a good look.

4. Fix it via automation, not manual re-entry

Once a mismatch is found, browser automation (Playwright, etc.) can walk through the normal edit → publish flow the same way a human would, just faster and across every affected item at once.

The takeaway

None of this required anything sophisticated — no ML, no scraping tricks, just diffing public data against itself. The interesting part is why nobody notices: creators trust the screen they're looking at. If the rendering layer never throws an error, there's no signal that anything is wrong. The only way to catch it is to stop trusting the UI and go straight to the data.

That's the poka-yoke mindset applied to a digital storefront: don't wait to notice the mistake, build the check that catches it automatically. This generalizes to any platform where content, pricing, and bundling are edited independently over time — the more edit history a page has, the more likely something has quietly drifted out of sync.

If you run a small store or content business and want a free pass over your own setup, feel free to reach out — happy to take a look.