Context
Small trucking companies in the United States buy dispatching as a service, and they pay for it as a share of what they haul. The going rate is 4% to 6% of the gross freight cost. On a fleet running thin margins that comes straight out of the profit, and it scales with success: haul more, pay more, for work that is largely a person refreshing load boards.
The other half of the problem is the dispatcher. An inexperienced one costs the company money in ways nobody itemises: loads taken at the wrong rate, deadhead miles nobody planned for, pickups missed, brokers left waiting. The owner sees the result in the monthly numbers and can’t trace it back to a decision.
Diagnosis
The discovery ran through forty owners of trucking companies. That number matters more than anything else in this case, because it happened before development, not after.
All forty confirmed the problem. Eight said they would use the product as soon as it worked. Those eight are the reason the MVP scope is two features and not ten.
The interviews also settled where the time actually goes. A dispatcher refreshes the board, opens a load, checks the truck’s position, works out cost per mile, decides whether the destination leaves the truck somewhere useful, then calls or emails the broker. Six minutes, give or take, from refresh to contact. In a market where the good loads are claimed in the order the calls arrive, six minutes is the whole game.
Decisions
- Scoped the MVP to two features: an automated load grabber and load analytics. Everything else moved to later stages
- Priced against the incumbent model rather than alongside it: a 1% service fee where the market charges 4% to 6%
- Staged the revenue model in three phases: a one-time access fee first, tiered subscriptions second, a transaction percentage once the AI carries the dispatch
- Positioned the analytics against DAT RateView on the one axis that decides a load: rate data updated continuously instead of every three days
- Sequenced the roadmap so the two revenue-bearing features ship in four months and the automated broker communication follows in two
Results
There is no revenue to report. The product was scoped, validated and modelled, and that is where this case ends.
What it produced: a defined MVP, eight companies waiting on it, a pricing model that undercuts the incumbent by a factor of four, and a revenue model that stays profitable at a fifth of the headline fee. At 100 clients running eleven trucks each, the model returns $2.2 million a year at 1%, and still $440,000 at 0.2%. Those are projections built on the interview data, not results.
The market sizing is the weakest part of the deck and I’d say so to an investor. A $987 billion target market is the freight market, not the software market, and quoting it flatters the opportunity. The number that carries weight is the eight companies, because they were asked and they answered.
What didn’t work
The revenue model went through three versions before it stopped depending on adoption I couldn’t defend. The first two assumed a subscription base that the forty interviews didn’t support: owners said they’d pay for outcomes, not for seats. Moving to a percentage of load value fixed the logic and cut the headline number, which is the correct trade and an uncomfortable one to put in a deck.