Logistics without the six-figure TMS

The problem

There's a wide band of shippers and third-party logistics operators who are too big for a spreadsheet and too small for a real transportation management system, and they've been stuck in that band for years. A regional distributor moving a few hundred orders a day. A 3PL running three warehouses for a dozen clients. A manufacturer that ships its own freight and has slowly built a shadow logistics operation out of email, PDFs, and a tab called "loads."

The enterprise answer to their problem exists, and it's genuinely capable — the established transportation management suites do real work. But the price of admission is brutal for a mid-market operator: license costs that run well into six figures a year, an implementation measured in quarters rather than weeks, and a systems-integration project with its own consultants and its own change orders. Enterprise TMS adoption has long skewed toward large shippers, precisely because of that cost-and-complexity floor. So the mid-market does what it always does when the tooling is priced out of reach: it manages a physical, time-sensitive, money-moving operation by hand, and absorbs the errors as the cost of doing business.

This post is about the middle path — modeling logistics operations on a configurable platform you run yourself, rather than choosing between a spreadsheet and a year-long enterprise implementation.

Shipments are state machines whether you model them or not

A shipment is not a row of data sitting still. It's a thing that moves through a sequence: created, planned, picked, packed, tendered to a carrier, in transit, delivered, closed — with exceptions branching off at every step (damaged, refused, returned, lost). Every logistics operation already runs this state machine. The only question is whether it's written down and enforced, or living in the shared memory of the dispatcher who knows that a load isn't really ready until the BOL is signed.

When the workflow lives only in people's heads and a status column, predictable things go wrong. A shipment gets marked "shipped" before it's actually been tendered. A load skips the check that should have caught a missing delivery window. Nobody can say with certainty who changed a status, when, or why, so a customer dispute becomes a search through email. These aren't failures of diligence — they're the structural result of tracking a process in a tool that has no concept of the process.

FastYoke models the shipment lifecycle as an explicit finite-state machine: a defined set of states connected by defined transitions, with guard conditions that govern when each move is allowed. A load can only advance along an edge that actually exists in the workflow — it cannot silently jump from "planned" to "delivered" with the tender and transit steps skipped, because that path isn't a value the system will accept. And because every transition is written to an append-only event log, the question "who moved this shipment and when" is a query, not an investigation. That's the same enforcement an enterprise TMS gives you — without the enterprise contract.

From the four walls to the road, in one system

The seam that hurts most in mid-market logistics is the one between the warehouse and the transportation side. In the enterprise world those are often two separate six-figure systems — a WMS and a TMS — connected by a custom integration that someone maintains forever. In the spreadsheet world they're two tabs and a copy-paste. Either way, the moment an order finishes being picked and packed and needs to become a shipment, data gets re-entered, and re-entry is where errors breed.

FastYoke closes that seam with a bridge between the Warehouse Management and Transportation Management apps: a completed, packed order becomes a shipment directly, carrying its references forward instead of being typed in again on the other side. The four-wall workflow — receive, putaway, pick, pack, ship — hands off to the transport workflow — rate, label, tender, track — on the same per-tenant database, with the event log spanning both. One customer's order-to-delivery history reads as a single continuous record, not two systems you reconcile after the fact.

Both apps sit on the same free Logistics core — facilities, zones, movements, and the immutable event log that every logistics app on the platform shares. That shared substrate is why the bridge is a native handoff rather than an integration project: the warehouse app and the transport app aren't two vendors' products bolted together, they're two configured workflows on one engine.

Routing you can actually change yourself

The daily routing problem — which stops go on which truck, in what order, without blowing a delivery window or a vehicle's capacity — is the part of logistics that most rewards good software and most resists doing by hand. It's a well-studied optimization problem: the Vehicle Routing Problem with Time Windows, a generalization of the classic truck-dispatching problem that's occupied operations researchers since the 1950s. Solving it by intuition on a whiteboard leaves real money — miles, hours, and fuel — on the table.

FastYoke's routing app takes your stops, each with a demand and a time window, plus your available vehicles and their capacities, and proposes capacity- and time-feasible routes you review, approve, and publish. Each run renders as a self-hosted route map — depot to stops to depot, drawn from your own coordinates, with no external mapping service in the loop and no per-lookup geocoding bill. Crucially, the routing objective and the constraints are yours to configure. The rules that decide what a valid route looks like live in the same workflow model as everything else, so adjusting them is a configuration change, not a support ticket to a vendor whose roadmap you don't control.

How FastYoke approaches it

Pulling the pieces together, here's what the platform gives a mid-market shipper or 3PL that an enterprise suite gives at ten times the cost and a spreadsheet doesn't give at all.

An enforced shipment lifecycle. The finite-state-machine engine makes the shipment workflow explicit and enforces it on every write — no skipped steps, no ambiguous statuses, every transition governed by a guard you define.

A warehouse-to-transport bridge. A packed order becomes a shipment without re-entry, with the Warehouse Management and Transportation Management apps sharing one per-tenant database and one event log across the whole order-to-delivery path.

Configurable route optimization. The routing app solves the capacity-and-time-window problem and renders self-hosted route maps, with the objective and constraints under your control rather than frozen in a vendor's product.

Multi-client isolation for 3PLs. Every client's data lives isolated by tenant, and the 3PL app posts storage and handling charges straight to a draft AR invoice in the built-in ledger — so per-client billing comes out of the same books month-end closes against, not a separate spreadsheet.

An append-only audit trail. Every state change across warehouse and transport is recorded in a ledger that's never edited or deleted — the record you hand an auditor, or pull up when a customer disputes a delivery, already exists.

What to watch out for

This is the honest part, and it matters more here than almost anywhere, because "cheaper than a six-figure TMS" is easy to hear as "the same thing for less." It isn't.

You configure it; it isn't a turnkey suite. An enterprise TMS arrives with a vendor implementation team, pre-built carrier connections, and a 24/7 support line you can escalate to at 2 a.m. FastYoke gives you the engine and the apps; you (or a partner) model your specific workflow, wire up your carrier accounts, and own the running system. That's the trade that makes it affordable, and it's a real trade. If you have no appetite to configure and need a vendor to own the whole thing, an enterprise suite is doing something FastYoke deliberately doesn't.

It's not a real-time dispatch or telematics platform. The routing app optimizes and publishes routes; it isn't a minute-to-minute re-dispatch engine reacting to live traffic, and the platform tracks vehicle and shipment records rather than ingesting live GPS or ELD feeds natively. Those are connector or partner integrations, not built-ins.

The deepest carrier and equipment integrations are SDK work. The common carriers plug in through a clean shipping-provider interface, but a private freight contract, an EDI feed to a specific customer, or a warehouse-control-system hookup for automated material handling is engineering — in-house against the SDK, or through a partner. If your operation lives or dies on one exotic integration, price that in.

If any of those is a genuine dealbreaker, the enterprise suite exists for a reason and you should buy it. FastYoke is the right call when you want the enforcement, the bridge, and the routing at mid-market complexity — without the six-figure license or the year-long implementation.

Where to go next

If you're running logistics out of a spreadsheet stack because the enterprise tooling was never priced for your shape, it's worth seeing what a configurable platform looks like against your actual flow. Take a look at warehousing & 3PL on FastYoke for the WMS/TMS/3PL side, fleet & transportation if you also run vehicles and maintenance, or compare plans on pricing to see where the routing and multi-client tiers land against what you'd pay an enterprise vendor.