Company
Built in Australia, for businesses that run their own vehicles.
boXe is a small team that has built operations software before, writing this one down completely before building it. No customers yet, no funding story, no logo wall: a specification, three prototypes and a build under way.
Why delivery, not warehouse
The gap is between the order arriving and the invoice going out.
The first version of boXe was warehouse-first: a stock ledger, receiving, pick-pack-ship, with delivery deferred. On 2 September 2026 that flipped, for three reasons.
Far more businesses run their own vehicles for recurring local deliveries than need a warehouse system, and most of them do not track stock in software at all. A warehouse-first product cannot be demonstrated without a warehouse; a delivery-first one can be demonstrated with a prospect's own order emails and yesterday's run sheet. And generic delivery software (routing, GPS, proof of delivery) is already well served and commoditised.
The stock ledger was the best piece of the old architecture. It is kept whole, as the Inventory module.
Principles
Six rules the build is checked against.
One system, one truth
Modules share a database; they never share a spreadsheet.
Delivery at the centre
Order, Prepare and Billing all attach to Delivery. The driver app is the primary operational surface.
Ledgers, not mutable columns
Stock and returnables are signed movements with derived balances. Corrections are compensating movements.
A model proposes; a person commits
Drafts everywhere AI touches. That line does not move.
Seams, not abstractions
Build the second concrete case before abstracting. Prepare is a seam; Inventory is its second implementation.
Horizontal architecture, vertical selling
One codebase, one data model. Packs are configuration; segment pages are marketing.