Trucks Leave With a Plan
What it took to build an automated logistics engine inside a landscape supply company, and why we built it inside the business instead of next to it.
The problem did not look like a software problem from the yard. It looked like a stack of printouts on a dispatcher's desk at six in the morning, a phone that would not stop, and a truck that left with mulch for a customer on the east side of Austin when the driver had been told the west side. Every one of those mistakes was small. Together they decided whether next-day delivery was a promise or a slogan.
We own trucks. We sell bulk mulch, gravel, soil, sand, and hardscape, and we deliver it the next day. That last part is the whole business. A customer who orders decomposed granite on Tuesday afternoon is comparing us on whether it shows up Wednesday, at the right address, in the right quantity, with someone who can be reached if it does not.
Why we built it inside the business
The easy move would have been to buy dispatch software and bolt it on. We did not, because we start with reality, not decks. Reality here was a storefront, a catalog with hundreds of variants of rock and soil, trucks with different capacities, a small number of drivers, and delivery constraints that change every day depending on what sold. Any tool that lived next to that reality would need someone to copy the reality into it every morning. That someone is the dispatcher, and the dispatcher already had a phone in each hand.
So we built the logistics engine inside the operating company, on the same stack as the storefront. The order that a customer places is the order the router sees. The quantity that a contractor confirms on a quote is the quantity that gets loaded. There is no second system, and so there is nothing to reconcile.
That choice also gave us something we could not have bought: every routing rule, capacity assumption, and delivery window was tried on real trucks going to real addresses. Some of those rules were wrong. We found out within a day, not within a quarter.
What shipped, in the order it shipped
The first paid orders went out in October 2025. At that point the storefront was the engine. Customers could buy, the yard could load, and delivery was managed by hand. We shipped that first because a logistics engine with no orders is a science project.
By March 2026 the routing and dispatch layer was live. Orders scheduled for a delivery day are grouped into routes. The router proposes a sequence of stops and estimates the drive time between them. A dispatcher can accept the proposal, reorder it, or split it when a truck cannot carry the full load. Manual dispatch stayed in the product on purpose. The machine proposes; the person who knows that one neighborhood has a low bridge decides.
The driver portal shipped with it. A driver opens the day's route on a phone and sees each stop in order, with the address, the material, and the quantity. When the truck is dispatched, the customer gets a text. When the material is on the ground, the driver takes a photo, adds a note if something was unusual, and marks the stop delivered. The customer gets another text. The dispatcher sees the whole day move without making a call.
Delivery slots came next, so the promise a customer sees at checkout is a promise the yard can actually keep on that day. Then the contractor program, with quotes that flow straight into orders and routes, because contractors buy in volume and buy on a schedule.
What an audit trail meant in practice
We say that speed wins, but only with an audit trail. In a warehouse that is not a slogan either. Every stop now has a timestamp, a photo, a note, and a record of which texts went out and when. Every route has a record of what the router proposed and what the dispatcher changed.
When a customer calls to say the gravel never arrived, the answer is no longer a shrug and a callback. It is a photo of the pile, a timestamp, and the note the driver left about the gate.
The audit trail is also how the engine improves. Skipped stops have reasons attached. Reordered routes show where the router's estimate was wrong. That record exists because the work was designed to leave a trace.
The part that moved into HiveOS
Most of what we built is specific to a yard in Austin. Some of it is not. Taking scheduled orders, proposing a sequence under capacity constraints, letting a human adjust it, and recording every decision is the pattern any delivery business needs. So is the loop of dispatch, proof of delivery, and customer notification.
Those parts have been pulled out of the company and into HiveOS as a reusable engine, with the yard-specific rules kept behind configuration. That is what we mean by build once, use many times. The company got a logistics system. The platform got a capability.
By September 2026 three engines are in production at the same company: logistics, commerce, and demand generation, the last one turning a described or photographed project into a priced cart and bringing in traffic through automated search and paid channels. They share one stack and one audit trail.
What we do about it
We keep the engine inside an operating business, because that is where it stays honest. We take the reusable pieces into HiveOS and leave the local ones where they belong. And when the next company in the portfolio needs trucks to leave with a plan, it starts on the second version, not the first.