Launch series: ← Part 1: the WiseTech turn · Part 2 (you're here) · Part 3: a forwarder's call → · Part 4: where we drew the line →
The last post ended on a downbeat. WiseTech cutting 2,000 jobs, the CEO saying the era of writing code is over, the commodity problem a whole generation of SaaS has on its hands. All of that is true. If it's the only half of the picture you've read, you'd leave thinking freight software is a bad business to be in right now.
I don't think it is. The rest of my thinking lives here, and it took me a while to talk myself into it.
The thing that flipped me was a March 2026 Sequoia piece by Julien Bek called "Services: The New Software." If you build in an adjacent space, read the whole thing — I'm not going to restate it at length here. But the crux is worth quoting directly:
"The next $1T company will be a software company masquerading as a services firm."
And the concrete example the piece uses to make the point:
"A company might spend $10K a year for QuickBooks and $120K on an accountant to close the books. The next legendary company will just close the books."
That second sentence did most of the work in my head. Every freight-tech company up to now has been in the business of selling QuickBooks-equivalents to forwarders. What Bek is describing is a world where the legendary companies are the ones that close the books — i.e., deliver the outcome, not the tool.
What this actually means for freight tech
Freight forwarders are themselves a services business. What they deliver to a shipper isn't access to a booking tool; it's the managed outcome — the shipment moves, the paperwork files, the compliance lands clean, the invoice reconciles, the exception gets handled. Forwarders bill for outcomes.
Every freight-software vendor I've looked at, including our past selves, has been asking the wrong question: how do we sell forwarders the tools that help them deliver their outcomes faster? The question that actually matches where the world is going is: how much of that outcome can we deliver directly, as software, and what does the forwarder pay us for when we do?
Two places that question gets interesting for Fr8Labs:
Inside the forwarder's own team. A huge slice of what a forwarder's ops team does every day is intelligence work priced as judgment work. Data entry. Quotation assembly. Rate sheet reconciliation. Arrival-notice reformatting. Customs declaration drafting. Status-report compilation. Each of those was historically human-only because no software could touch it; each is now a candidate for AI to produce 80–90% of the output with a human on review. That's the translator layer I've been writing about — but the services-as-software framing sharpens what it actually is. It's not an efficiency gain on top of a modern FMS. It's a different product: an AI colleague a forwarder pays for on outcome terms, not per-seat.
Outside the forwarder, in the ecosystem they've always had to outsource. Insurance. Payments and cross-border settlement. Customs brokerage. Compliance and documentation. Financing against deferred-terms freight. Each of those is a services category — large, fragmented, already-outsourced, intelligence-heavy. Each is what Bek's piece would call a wedge candidate: a services budget that previously flowed past the forwarder to a specialist, and that a software vendor can plausibly deliver as software now.
Most freight-tech vendors call those "integrations." Connect to a partner, hand off the business, collect a small revenue share, call it an ecosystem strategy. That framing is about to age badly. The services-as-software lens makes clear these aren't integrations — they're the largest slice of where freight spend is actually going, and AI is the unlock that makes them addressable from the platform the forwarder already lives in.
The two bets this commits us to
Fr8Labs' two biggest investments in 2026 are both downstream of this thesis:
Bet one — the translator layer. Capture a forwarder's tacit knowledge in the normal course of daily work; use AI to deliver the intelligence-work outcomes that used to require headcount; let the forwarder's team focus on the judgment work that makes the brand what it is. This is what most people think the AI story for freight is. It's only half.
Bet two — the ecosystem services layer. Go deeper into the categories forwarders previously had to outsource. Not as "integrations" but as products we deliver directly. Insurance, payments, customs, financing, compliance, forwarder-to-forwarder networks. These are moat-dense in a way that traditional SaaS never was: the more forwarders we serve, the more claims data + routing data + compliance data we accumulate; the more data, the better the AI-delivered outcomes; the better the outcomes, the harder we are to switch off. This is where the defensibility of the next decade gets built, and where we're leaning in hardest.
Those two bets multiply. The translator layer makes a forwarder's own team operate at multiples. The ecosystem layer expands what the forwarder can sell. A forwarder on Fr8Labs should be able to serve more shippers with the same team (translator), and capture more margin per shipment (ecosystem). Both at once.
The people worried about freight software in 2026 are worried about whether the old shape of software survives. That's the pessimist half. The optimist half — the half I keep landing on — is that the thing we build over the next five years is going to be bigger than what any pre-AI freight software company was ever going to build. It just has a different shape.
The innovator's dilemma, and why we want to be on the other side of it
Bek's piece ends with a warning I think about a lot. Selling outcomes means cutting your current customers out of doing that work themselves. A vendor that built on selling tools to a function will struggle to sell that function's work instead of that function. The revenue models don't point the same direction. The sales motions don't know the move.
Freight incumbents are on the wrong side of this. Their revenue model is charging forwarders for tools that make their existing teams faster. Replacing those teams isn't what their account reps have spent twenty years pitching.
We came in late enough to not have that baggage. We've built the platform, but we haven't built thirty years of revenue habits on top of the wrong part of the forwarder's org chart. That's an advantage, and we intend to use it.
What I'd ask you to take away
If you're a forwarder reading this: the software conversation is about to stop being about modules and start being about outcomes. The question that cuts through the noise: what is the vendor willing to take ownership of, and what do they still hand back to my team?
If you're building software adjacent to us: I cannot recommend Bek's piece highly enough. Even if your industry isn't freight, the structural logic of services-as-software applies anywhere customers currently pay for outcomes delivered by humans doing intelligence work.
If you're an investor thinking about freight: the next generation of winners here won't look like software companies in the traditional TAM sense. They'll look like operators of outcome-delivery at software margins, with a thin layer of judgment work kept by a small human team, and moats built from data, integration depth, and network effects. Not features.
I opened this post by saying I stopped being a pessimist. What I actually mean is: the crisis I described in Part 1 is real for one kind of company. The opportunity — the one Bek's piece makes legible — is real for a different kind. Fr8Labs is trying to be the second. That bet is why I'm more excited about this year's roadmap than I've been about any roadmap since we started.
The next post in this series is about one specific forwarder conversation that made me sure we're on the right side of this.
— Glenn
