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.
Top comments (0)