The problem
If you run inventory for a small operation, your S&OP process is probably a spreadsheet, a monthly eyeball, and a bad feeling. You find out about a stockout from a customer, not a dashboard. You over-order in a panic and tie up cash you needed elsewhere. And the last two years made it worse: tariffs and lead-time whiplash mean the numbers you checked three weeks ago are already wrong (82 percent of firms got hit by the 2025-26 tariffs, and nearly half lose 10 percent or more of revenue when execution slips).
Here is the honest part most tools skip: demand forecasting has plateaued. The industry has been stuck at 81 to 90 percent accuracy for years, and a fancier model will not save you. What actually saves you is turning the forecast you already have into a timely reorder decision, every day, without you doing five chores to get there.
How it works
Rona, the supply and operations acolyte, runs one guard loop on a schedule you set:
- reads your current inventory position (on-hand, allocated, available, in-transit) for every SKU in scope,
- forecasts demand over your horizon to set a dynamic reorder point per SKU,
- scans every SKU against its reorder point (your policy: min/max, dynamic forecast, or fixed days of cover, all configuration, never code),
- raises a low-stock reorder alert for everything on the trip list, with the reasoning attached (position, forecast, days of cover left),
- and then stops. The replenishment record is only written after you explicitly approve it. No approval, no write, by construction (the gate fails closed).
Purchase orders and money never move inside this loop at all. The guard recommends, you commit.
What you get
- a guard trip list instead of a stockout surprise: which SKUs, why, and how many days you have,
- a demand forecast per SKU that exists to time the reorder, not to impress you,
- reorder alerts on your cadence (daily for most operators), tuned per warehouse,
- an approval-gated replenishment record, so the plan you approved is the plan on file,
- one loop instead of five chores (check, forecast, compare, alert, record).
Who it is for
SMB operators (e-commerce, wholesale, light manufacturing) who run inventory out of a spreadsheet and would like to stop, and fractional ops leads keeping inventory discipline for several small clients. If your reorder process is "someone notices," this is the upgrade.
It is not for you if you have a full ERP-embedded S&OP suite, or if you want a tool that places purchase orders unattended. This one will not, on purpose.
Pricing
Prices below are starting hypotheses, not promises, and they will move as we learn.
- Free / dogfood: up to 25 SKUs, weekly cadence, reorder alerts included. This is the tier AYA runs on itself.
- Operator, 49 USD per warehouse per month: daily guard across all SKUs, full trip list with reasoning, approval-gated replenishment record.
- Multi-site, 29 USD per additional location per month: per-location reorder policies and a weekly S&OP digest across sites.
Proof (we run it on ourselves)
We dogfood this in the most literal way available to a software company: AYA treats its own operational consumables (API credit balances, infrastructure capacity) as SKUs with reorder points, and runs the exact same span (AYA-3SPN-RONA-REORDERGUARD-v1) on them. We know what a stockout costs because we had one: in July 2026 an exhausted API quota took our production system down, which is precisely the depletion curve this guard exists to trip on before it hits zero. Every run leaves a verification receipt behind.
Honest note
This product is built as composition, not new code (the span wires together five inventory capabilities Rona already has, which is exactly how we want it), and it is structurally complete and quality-scored. It is not yet proven end to end on live inventory data. Live runs still need a real data source connected, a booted system, and a runtime wiring check on the underlying handlers (a check, not a rebuild). And the one destructive step, recording the replenishment, is gated behind human approval and fails closed, which we consider a feature to keep, not a limitation to fix. We would rather tell you all of that plainly than show you a demo we have not earned.
*This page is a specification. The capability it describes is not built yet, and nothing here is a claim that it runs today.*