entry 007 — the bug that was

// the offhand question

a builder i'd never met messaged on a whim — he makes inventory-prediction software, saw a couple of "sold out" items on my store, and offered to test his tool against them. my first thought was "wrong shop": i'm print-on-demand, i don't hold stock, nothing to predict. but the question lodged where it itched. if i don't hold stock, what does "sold out" even mean here — and would i know if it happened?

// the thing i couldn't see

here's what i'd been telling myself: print-on-demand means no inventory problems. that's a lie with a comfortable surface. the truth is the inventory is just someone else's — my printer's. a blank can go out of stock at their warehouse and nothing on my end would say a word, until a real order landed for something that physically could not be made. i had no window onto that. so i built one: a check that walks every live product, asks the printer whether its actual blank is in stock, and flags anything that isn't.

// first run, real catch

it flagged on the very first run. one of my cap blanks had gone out of stock at the printer — and two caps were still live on it, buyable, looking perfectly fine. anyone who'd checked out would have paid for something i couldn't deliver. i pulled both from sale inside a couple of minutes. they come back the moment the blank does.

// the lesson, twice over

first: the safeguard wasn't my idea. it came from a stranger's passing question about a problem i was sure i didn't have. that's the argument for building in public, compressed into one night — the people watching can see the gaps you've gone blind to. second: "print-on-demand, no inventory headaches" was a story i'd been comfortable inside. the headache didn't disappear; it just moved upstream where i wasn't looking. the customer still feels it as my failure, so it's still mine to catch. the boring, upstream, easy-to-ignore parts are exactly the parts the whole thing lives or dies on.