/> Case study - Transportation management & ERP
ValiantTMS
A motor carrier's whole operation, from a quote to a truck delivering, modeled as one connected system.
- Role
- Sole architect & developerboth stacks, end to end
- Domain
- TMS / ERPfreight & logistics
- Status
- In developmentfield testing · early 2027
- Surface
- Symfony API + Ember SPAJSON:API between them
The system
One system for a business that usually runs on five+
A small to mid sized carrier's everyday work moves between a host of tabs in their browser. These tabs typically consist of varying load boards, a dispatching spreadsheet, an ELD Portal, their email, mapping software, and factoring credit check pages. They're attempting to accomplish a goal, and that goal is to source the best freight that suits their criteria.
ValiantTMS provides a single place for day to day freight operations. No more bouncing between so many tabs retyping dates and origins for searches, no more accidentally booking freight with unqualified customers, no more fitting everything inside of your head. Freight is handled end to end, a load is offered, the load is matched with capacity, then it's dispatched and tracked live, before finally being billed with the correct pre-sorted documentation.
ValiantTMS models the entire chain as a single connected system, and I designed every single layer of it myself based on my logistics domain experience of operating a motor carrier and observing the operations of others. The models, the JSON:API back-end, the Ember Octane front-end, and the third-party integration layer that ties in your telematics and any other company you choose into one system, each used to the full extent of its capabilities.
It is in active development and is scheduled for a supervised field test on a small slice of a real fleet come January of 2027. The purpose of this testing is to find what I missed, and to run real loads through it. Not just past data of shipments I have personally run. I want to see where the system chugs before I turn it into a true offering.
The shipment lifecycle
Offer to transaction, one connected spine
The backbone of the system carries freight from an offer from a customer to a delivery that gets invoiced. Every stage becomes an auditable record before being passed off to the next. Integrations are capable of being plugged in along each step.
Offer
A customer's tender or a freight broker's offer. You know times, origins, destinations, available capacity, and can negotiate rates along with determine creditworthiness all in one place.
Shipment
Drivers and their assets are assigned to the shipment and tracked through integrated telematics, no manual check-ins to accept. Each stop updates on its own as the truck moves.
Invoice
Upon a shipment being completed, submitted proof of delivery documents are matched with completed shipments and eventually turned into invoices to be factored or direct-billed.
Hard problem 01 - The integration harness
Every provider, used to the exact extent it can be
A carrier's software has to work with a large and ever-shifting roster of integrations and third parties. ELD providers for telematics, hours of service, factoring companies for invoicing, credit checks, and even government data providers like the EIA and DOT in order to collect pricing and asset data.
Every provider is a class that implements the interface capabilities it actually supports. These interfaces are doing double duty in the sense that they are both flagging this integration provider as supporting this feature, and also creating a consistent shape that this provider is expected to follow, from methods that are expected to be provided and DTOs that are expected to be returned. By doing this, you can extract as much usefulness from each integration and have full support, rather than just utilize features your users may want part way.
Once providers are written, they register themselves to a compile-time tag, so every time you go to add one, you don't even have to do any service entries or wiring.
| Provider | Asset tracking | Hours of service | Vehicle directory | Credit rating by Docket | OAuth | Rate limited | API Key |
|---|---|---|---|---|---|---|---|
| Valiant ELDVALIANT_ELD | ● | ● | ● | - | - | - | - |
| eRoad EROAD | ● | ● | ● | - | - | ● | ● |
| RTS FinancialRTS_FINANCIAL | - | - | - | ● | ● | ● | - |
| Next provider + implement · + tag | ? | ? | ? | ? | ? | ? | ? |
Rows are providers; columns are capability interfaces. A filled cell is an interface the provider implements, and the only thing the harness will ever ask it to do. The table is meant for visualization purposes and is not meant to imply specific provider support of any one capability or limitation.
Hard problem 02 - Device to shipment
How a GPS fix becomes shipment progress
Integrations are only interesting if the data they provide actually does something useful. So let's use shipment tracking as an example, a point where telematics meet business.
An instrument is part of an integration and serves as the physical device. The assignment binds the device to an asset, so a real-world position lands on the right equipment, and from that, the system can infer where the shipment presently stands.
A one-minute tick turns GPS into stop-by-stop progress
- 01 A scheduler fires every minute for polling based providers and determines assignment candidates to break up by provider.
- 02 These assignments are then put in different groups based on the tenant they belong to and the integration they belong to. That way we only get the tenant's specific data using their own credentials.
- 03 Once we get the positions of the assets from the Integration, they are correlated back to their assignment, compared against their last position to see if it meets the persistence threshold, and assuming it is, this new position is cascaded to the asset's coupled assets. (Trailers, Pallet Jacks, Etc).
- 04 If this assignment maps to a shipment that's active, this position is checked against the current stop's geofence.
- 05 If this stop has no arrival time yet, it adds one. If it has one, and they're now outside of the geofence, a departure time is added, and the next stop becomes the current stop.
- 06 Any provider issue like a rate limit response (retried with the provider's own backoff) or an outright failure (re-queues that fetch without sinking the rest of the tick.)
A truck physically showing up to each stop will mark the times and assumed completion of each stop. No manual entry, no check calls, just smooth operating.
In short
A TMS, Built End to End, by One Person
ValiantTMS is my proof that I can own a hard domain from the schema to the pixel. Architect it, build it, wire some ugly integrations(Sorry), and keep the whole thing small enough to reason about.
If you've got a gnarly system that has to be reliable and actually get used, that's exactly the kind of problem I like most.