Every order management rebuild starts the same way: someone exports a month of orders into a spreadsheet, finds the reconciliation gap, and decides the current system has to go.
Six months later the project is late, the old system is still running, and nobody wants to talk about it.
The scope is written from the happy path
Teams specify what should happen when an order arrives, gets picked, gets packed, and ships. That path is maybe 70% of real volume. The remaining 30% is where the work actually is:
- partial shipments across two warehouses
- a cancellation that lands after the picklist is generated
- a courier that silently reassigns a tracking number
- returns that arrive before the refund is approved
If those are not in the spec, they get discovered during UAT, and the estimate was never real.
Inventory is treated as a number
It is not a number. It is a number per location, with reservations, in-transit quantities, and a rule for what happens when two channels sell the last unit within the same second.
Any system that stores stock as a single integer will eventually oversell. The only question is whether that happens before or after launch.
We learned this building VBOS, our own multi-tenant OMS and WMS. Running it in production means we hit these problems on our own time rather than a client's.
What we do differently
- Model the exceptions first. We write the awkward cases into the spec before the happy path, because they drive the data model.
- Keep an audit trail from day one. Every state change is recorded. When operations disagrees with the system, the log settles it.
- Ship to one warehouse first. Real orders through a narrow slice beats a full rollout that nobody trusts.
None of this is clever. It is just the order of work that stops a rebuild from becoming a rewrite.