Laneflare: AI dispatch and a TMS for expedite trucking fleets
Laneflare is my own product for small US expedite carriers. Alerts from every load board land on one board, the system picks the truck that fits and drafts the bid for the dispatcher. The product, its landing page and its infrastructure are designed and built by one person.
Context
Small expedite carriers run sprinter vans, box and straight trucks and find freight on load boards. A dispatcher watches dozens of alerts, checks each one against where the trucks are and answers the broker by hand; the first sensible bid usually gets the load. Laneflare started as a system for one such fleet and became a product for carriers like it.
What was built
One board for every alert. Postings arrive by a workflow every two minutes, each tagged with its source board; loads that left the board are marked expired. Statuses Available, Bid Sent, Booked and Expired, and a separate view for each truck.
The right truck first. Every posting is checked against the drivers’ location, search radius, equipment and payload, and the nearest truck that fits is shown in the row. The broker’s credit rating is looked up by MC number, a repost of the same lane by the same broker is flagged, low-rated brokers go to a hidden view.
A bid in two clicks. Send quote opens a prefilled bid: recipient, subject, all-in rate and message. The load moves to Bid Sent and keeps the amount.
From the bid to delivery. Order actions walk the load through quote, booking, order and dispatch; the driver gets a message with map links. Rate confirmation and bill of lading are generated as PDF from the order. Trucks and loads are on a live map, and every change reaches open screens over WebSocket without a reload.
The landing page. laneflare.com is a static page without a framework. The load grid in its first screen is rebuilt from the product’s own screen configuration, so the page shows the real columns, statuses and colors.
How it works
Laneflare runs on the configuration platform I worked on in a team: screens and processes are YAML in a separate repository, while the .NET backend and the React frontend are shared and know nothing about trucking. The board, the statuses, the matching rules and the documents are configuration. The backend only got generic building blocks: a driver matching task, live subscriptions, expression functions for workflows.
On the way the workflow engine got faster: creating an order through a workflow went from 155 to 19 ms.
Every change ships automatically to my own infrastructure: an image build bumps the tag in the cluster repository, ArgoCD rolls it out.
