The most expensive stockouts are rarely the dramatic ones. They're the quiet reorders that never happen because nobody caught the gap in time.
A founder's story
Most of what gets written about stockouts comes from analysts, not from the people who actually ran out of product. So it's worth reading what a founder said about it directly.
Emre Doganer, who built a posture-correction device brand called Straight under his company Kodgem, wrote a post on Indie Hackers in May 2025 titled "$1M Revenue, $0 Profit: Our D2C Reality Check." In it, he lays out what he calls "Inventory Planning Disasters":
"Our limited capital meant we could only produce 1,000 units at a time. But here's the kicker, each subsequent production run cost MORE per unit, not less. Small batch productions meant higher per-unit costs. We'd run out of stock during peak demand periods. Emergency productions came at higher costs to meet demand. No economies of scale because we couldn't afford larger runs. Storage costs ate into margins when we did overestimate demand. And we had to throw away expired or damaged inventory multiple times. The cycle was vicious: make 1,000 units, sell them, need 2,000, can only afford 1,200, pay higher per-unit costs, repeat."
(Source: Indie Hackers, "$1M Revenue, $0 Profit: Our D2C Reality Check", May 26, 2025.)
What stands out is that Doganer's team was hit by both halves of the same problem: running out of fast-moving stock at the worst possible time, and separately, throwing away inventory that expired or got damaged before it sold. Different failure modes, same root cause: nobody had a system watching stock levels and shelf life closely enough to act before the damage was done.
Elaborating the pain
The reason this keeps happening isn't that founders don't care about inventory. It's that most inventory checking is periodic, and demand isn't.
A team checks stock levels once a day, or once a week, or whenever someone happens to open the admin dashboard. Between checks, sales keep happening. A product that had 40 units on hand yesterday can be at zero today if a post goes semi-viral, an influencer mentions it, or a restock email goes out. The gap between "running low" and "actually gone" can close in hours, and a periodic check only catches it after the fact, usually when a customer already tried to buy and couldn't.
Fast-movers get hit hardest because they're exactly the products where the gap between checks matters most. A slow-selling SKU can sit at low stock for weeks without anyone noticing. A fast-selling one can go from healthy to sold out inside a single day, and that's usually the SKU driving the most repeat revenue, which makes the miss more expensive than an ordinary stockout.
Shelf life adds a second version of the same problem, quieter but just as costly. A product isn't just "in stock" or "out of stock," it's also somewhere on a clock toward its expiry date. If nobody is watching that clock, a batch can go from sellable to unsellable without any single moment where it looked urgent. Nobody decided to lose that inventory. It just aged out while attention was elsewhere. That's the mechanism behind Doganer's line about throwing away expired or damaged inventory multiple times: not one bad decision, but the absence of a system that would have flagged it in time to run a clearance push before the deadline passed.
What a solution could look like
There's a real range of ways teams try to solve this, and it's worth being honest about what each one actually covers.
Spreadsheet spot-checks are cheap to start, and for a very small catalog they can work for a while. The problem is they depend entirely on someone remembering to open the file, and they degrade fast as SKU count grows. There's no concept of urgency either: a spreadsheet doesn't page anyone when a threshold is crossed, it just sits there being slightly out of date.
Native platform low-stock notices (Shopify and most others have some version) are a step up, but the threshold is usually coarse, often a single fixed number across the whole catalog. That doesn't distinguish a slow-moving SKU sitting at 5 units for months from a fast-mover about to sell through its last 5 units by evening. It also generally has nothing to say about expiry dates, since that's not data the platform tracks natively.
Dedicated inventory-management SaaS genuinely solves more of the problem: multi-location tracking, demand forecasting, sometimes reorder-point calculations. The tradeoff is that these tools are built for the average case, so it's common to end up paying for forecasting features that go unused, or configuring around a data model that doesn't match how a specific brand actually tracks batches and expiry, if it covers expiry at all.
Hiring an ops person to watch it works, and for a brand with the volume to justify a hire, it's a reasonable answer. But it's a recurring cost for a job that's fundamentally about checking numbers against thresholds and flagging when they cross, which doesn't need a person doing it manually forever.
A fully custom, continuous-monitoring automation is the option that actually closes the gap between "running low" and "someone finds out," because it isn't checking periodically or waiting for a person to look. It's also the option that takes the most work to set up correctly, since it has to be built around the actual data source and the actual thresholds that matter for a specific catalog. That's the version I'd build.
The solution I'd build
Here's how I'd build this: every SKU gets its own threshold, checked continuously rather than on a schedule someone has to remember to run.
The system pulls stock levels directly from wherever inventory actually lives, the ecommerce platform's inventory API, or a POS system if the brand sells offline too. Each SKU gets a threshold based on its own sell-through rate, not one flat number for the whole catalog. A slow-mover might get flagged at 10 units left. A fast-mover with a two-day sell-through might get flagged at 30, because that many units can disappear fast enough that waiting for single digits means it's already too late to reorder in time.
When a SKU crosses its threshold, two things happen automatically. A draft reorder gets generated, quantity based on recent sell-through and lead time, vendor details pre-filled from what's already on file, so nobody has to dig up the supplier's contact under time pressure. And a notification goes out the same day, not batched into a weekly digest, so there's actual runway to act before the SKU sells through completely.
Where shelf life matters, a second, parallel check runs against expiry or best-by dates on each batch. It's its own clock, separate from stock-level logic: a product might have plenty of units left but be 30 days from expiry, which is a different kind of urgent than "about to sell out." That triggers its own alert, early enough to run a clearance push or a bundle offer instead of writing the batch off as a loss after the date has passed. This is the piece most brands don't have any system watching at all, they have eyes on stock level and nothing on the second clock running underneath it.
Both checks log to one place, so a team looking at the day's flags sees stock-level and expiry issues side by side, not two systems that never talk to each other.
Pros and cons
I'd rather lay out the real tradeoffs than pretend this is a clean win.
What it actually solves: the lag between "running low" and "someone finds out" closes from days or weeks down to same-day, for every SKU, without depending on a person remembering to check. The reorder draft removes a chunk of manual work at the exact moment someone's least likely to have time for it. And for perishable categories, it adds a layer of visibility most brands don't have: a second clock running next to the stock-level one.
What it doesn't solve, and where it can go wrong:
- It's only as good as the inventory data feeding it. If the platform's stock counts are wrong or out of sync with a warehouse's actual shelves, the system will confidently alert on bad numbers. Garbage in, garbage out applies here as much as anywhere.
- Thresholds take iteration to get right. Set them too conservatively and the team gets alerted on SKUs that were never actually at risk, which trains people to ignore the alerts. Set them too loosely and it misses the fast-movers it was built to catch.
- It doesn't fix a broken supply chain. If a vendor has a six-week lead time and sell-through is faster than that, an earlier alert helps, but it doesn't manufacture inventory that isn't coming. It tells you sooner. It doesn't make the truck arrive sooner.
- Alert fatigue is a real risk, not a hypothetical one. A system that fires too often on the wrong things gets muted, and a muted alert system is worse than no system, because it creates false confidence that something's watching when nothing is.
- It adds a dependency: threshold reviews as sell-through patterns shift, checking the data connection stays live, someone owning it so it doesn't quietly stop working unnoticed.
How it gets implemented
The data source has to be the actual system of record for stock, whatever platform or POS holds the real numbers, pulled via API rather than re-entered anywhere. Re-entry is where these systems usually break down in practice, adding a manual step back into a system meant to remove one.
Monitoring cadence should be as close to continuous as the data source allows, polling on a short interval rather than once a day, since the point is catching the gap between checks that a periodic process can't close.
Threshold logic runs per SKU, calculated from recent sell-through rate and supplier lead time rather than one flat number applied across a catalog with both fast-movers and slow ones in it. Where expiry matters, that's a separate rule set: days-to-expiry thresholds tied to batch or lot data, checked independently of the stock-level logic, because a SKU can be fine on one axis and urgent on the other.
Draft-reorder generation pulls the last known vendor, unit cost, and lead time for a SKU, calculates a suggested quantity from recent velocity, and holds it as a draft rather than auto-sending a purchase order. A person still approves it, the system just removes the blank-page problem of starting a reorder from scratch under time pressure.
Notification routing goes to wherever the team actually looks first, not a channel that gets checked once a week. Same-day delivery matters more than the specific channel, and stock-level versus expiry alerts probably deserve different urgency framing so neither gets treated as background noise.
KPIs: the cost of the pain, and the cited improvement
The clearest number on what this problem costs comes from Aislestock's 2026 retail stock management research: $1.2 trillion is lost to stockouts across global retail every year, and up to 55% of shoppers permanently switch to a competitor after repeated stockouts. That's an industry-wide figure, not specific to any one brand, and it should be read that way.
But the mechanism that prevents it doesn't care about scale: a threshold check that fires before a human notices costs roughly the same to run whether a brand carries 50 SKUs or 50,000.
Where this shows up in practice is documented most clearly in beauty and cosmetics, where reorder alerts on fast-moving skincare are common, and in health, nutrition, and wellness, where the expiry dimension matters as much as the stock-level one, and where Doganer's own account of throwing away expired inventory multiple times fits the pattern directly. The same two-layer problem, stock level and shelf life, almost certainly extends to food and beverage and any other category carrying perishable inventory, even though that vertical isn't part of the research cited here. Most brands only have eyes on the stock-level layer. The expiry one runs quietly underneath, uncounted, until a batch is already a write-off.