Launch series: Part 1 (you're here) · Part 2: the optimist turn → · Part 3: a forwarder's call → · Part 4: where we drew the line →
Some time in early 2026 — I don't remember the exact day — I was building our Notification Hub module personally, alongside the team, working in whatever evenings and quiet afternoons I could find. Notification logic is one of those things that sounds simple for two weeks and then isn't; it's the layer that decides how our platform talks to customers, carriers, and the forwarder's own team across email, WhatsApp, portals, and a few other surfaces. I wanted to see if I could ship something grade-A without pulling an engineer off the roadmap.
I could.
The thing I didn't expect was the second-order effect. By the time I finished a first shippable version, I'd also figured out a pattern that the team hadn't been using: SDK-embedded first. Instead of building a full new module with its own screens and navigation, I embedded the capability directly into our existing core surface — a thin interactive layer inside a workflow people already use, rather than a separate destination. The tradeoff was deliberate. Lighter UX, but I could iterate at the speed of code without going through a full product cycle.
I showed the team. We turned it into a rule: for experimental modules — features that aren't 100% proven yet — we build SDK-embedded first. Graduate to a full module only when usage earns it. Our upcoming AWB stock module will start this way. It's already changed how our product team decides to invest.
I want to open with this because it's the part of the story that usually gets told last, if at all. The WiseTech news broke in February and a lot of people wrote good pieces about what it meant. I had some thoughts on what it meant too. But the WiseTech announcement is not the reason my thinking changed. My thinking had been changing for months, from the inside out, because I was personally feeling the leverage shift. WiseTech was the moment it became impolite to keep pretending otherwise.
Three threads, converging
By the week of the WiseTech announcement, three threads had been braiding in my head for a while.
Thread one — personal. The Notification Hub build wasn't an outlier. It was the latest in a quiet series of things I'd been doing alongside the team — things that in 2024 would have taken a month and an engineer, and that in 2026 I was finishing in an afternoon. The pattern was consistent. It wasn't speed exactly. It was scope — the range of things I could credibly push forward without waiting on capacity somewhere else in the company. When an individual operator's effective scope grows by an order of magnitude, something has to change about how companies are organized. I was watching that happen inside me, a sample size of one, but the sample felt generalizable.
Thread two — market. Thirty percent of Microsoft's code is AI-generated. A quarter of Google's. Most of Meta's, soon. Nvidia's CEO publicly told his engineering organization that if a $500K engineer isn't consuming at least $250K of AI tokens a year, there's a problem. When the production function for software collapses by an order of magnitude, the market for quality software changes with it. "Software is a moat" was a true sentence for thirty years. It is not going to be a true sentence for the next ten. I don't say "SaaS is dead" because it isn't — there are companies with real network effects and real distribution that will print for another decade. But a whole generation of SaaS has a commodity problem on its hands, and most of them haven't named it yet.
Thread three — industry. Freight tech, specifically, is an exposed position. The incumbent playbook — long legacy TMS codebases, slow product cycles, six-figure quotes into the mid-market — depends on code being expensive to produce. The customer behavior the incumbents quietly count on (inertia, switching cost, the comfort of the familiar) depends on customers believing that whatever comes next will take five years to arrive. The AI-native version isn't five years away. It's now-ish.
The week WiseTech said it out loud
"The era of manually writing code as the core act of engineering is over."
That's the CEO of WiseTech Global — the company behind CargoWise, which processes something like three-quarters of global customs transaction data. He said it when they announced they were cutting two thousand jobs, nearly a third of their workforce, across forty countries. February 2026.
When a CEO of the largest platform in legacy freight tech makes that statement, it's not a line in a press release. It's the public admission that a specific kind of software company is not the thing to be going forward. Everyone adjacent to that kind of company heard it the same way I did.
I called Felix the same morning. The conversation wasn't about whether AI was real — we'd been using it internally for months; that debate was over for us. It was about a less comfortable question: if code is cheap now, what are we actually selling?
What I kept trying to talk myself out of
The first answer I reached for was "we're selling software." That's the answer every founder in this space has been trained to give — a modern FMS, integrated accounting, an AI-native forwarder platform. Fine words. They stop meaning much the moment the production function for all of them collapses. My own example half-disproved the answer: if I could ship a production-grade module on evenings and weekends, what exactly was our product team doing that any competent operator with equivalent tooling couldn't replicate?
The second answer was "we're selling better software." Also lazy. The quality bar on a shipments grid is not the thing that makes a forwarder pay you, and it never was. It felt that way only because we compete against a slow-moving incumbent.
What made me uncomfortable is that both of those answers are answers I have given — in decks, on calls, in investor rooms. I don't think they were wrong. They were narrower than the actual opportunity, and I hadn't been forced to see past them.
What the answer actually seems to be
A friend in a different industry — adjacent to manufacturing, so an outsider to freight — put it to me this way: "code is the cheapest input in your company now. Context is the most expensive." I've been sitting with that.
For a freight forwarder, the context that makes a platform useful doesn't live on a documentation site.
- Why a shipment that looks fine on the dashboard is actually flagged in your operator's head because the shipper's paying cycle lines up with Chinese New Year.
- Why you charge this customer a lower margin but terms are net-30, and that customer is net-60.
- Why an arrival notice from this port is different from the same port three years ago, because the local authority reshuffled filing rules that never made it into any training set.
- Why your ops planner avoids a specific carrier on Tuesdays.
None of that lives in the code. All of it lives in the heads of the people who do the work.
The job of a freight software company in 2026 is not to generate more screenshots of more modules. It's to build a platform that collects that tacit context in the normal course of daily work, and makes it available to AI agents so the forwarder's team can operate at a multiple of today's productivity without having to become engineers.
It sounds obvious when I write it out. It was not obvious to me three months ago. I think that's worth admitting — the speed of the shift is part of the story.
What changes in practice
I haven't stopped thinking of Fr8Labs as the operating system for freight forwarders — that identity is stable, and it's the right one. What has changed is what sits on top of it and what sits inside it.
Two things are compounding now that weren't a year ago. First, a translator layer that captures a forwarder's tacit knowledge and makes it executable by AI — not as a bolt-on, but as a surface the platform is deliberately designed around. Second, a deeper investment in the ecosystem layer — insurance, payments, customs, forwarder-to-forwarder networks — where integration depth and network effects are genuine moats that don't evaporate when code gets cheaper. Those are the things we're leaning into harder than we were last year, because those are the things that don't commoditize.
The modules are still there. They have to be. Accounting, shipment records, CRM, customs filings — the whole Operate stack — doesn't go away because you wrote an LLM wrapper. What changes is what sits on top, what sits in between, and which investments compound. We've redirected a nontrivial amount of engineering effort toward the translator layer and the ecosystem layer, at the expense of what the old version of our roadmap called "feature parity."
Three practical consequences:
- Every new feature has an AI seam. Baked in, not bolted on. If a feature can only be driven by clicks, it's legacy on arrival.
- Investment is shifting from more modules to better context capture + AI orchestration. A bigger change in how our team spends its time than the module list implies.
- How we talk about the company has to change. The old vocabulary — modules, pillars, platform — is accurate but insufficient. The town hall I ran internally was one expression of that shift. The new website you're reading is the first visible external one. This blog is the second.
What I'm still wrestling with
A few things.
Where is the line between "we're an AI translator" and "we're still the system of record for money and cargo"? The second is not optional — customers pay us to be the vault. The first is what the next decade rewards. They aren't in conflict, but they have to be held in tension, and the tension has to be visible in what we ship. Part 3 of this series is the engineering half of that answer. I don't think we're done refining it.
How defensible is any of this at the scale a WiseTech operates at? I don't know yet. The working thesis is that defensibility comes from being closer to a mid-market forwarder's daily reality than an incumbent can stay. That's an argument I have to keep earning against real competition, not just typing it into an essay.
What if we're wrong? I come back to this a lot. The way I size it: if I'm wrong about the translator layer being where the next decade is, we've still spent 2026 making Fr8Labs faster and more AI-native at everything it already does — that time isn't wasted. If I'm wrong about "ship more modules" being where the next decade is, we've spent 2026 building a feature-parity version of a software company that won't matter in five years. The downsides aren't symmetric. So we take the bet with the smaller downside, and we watch.
This is the first of four pieces. Part 2 is why this pessimist case actually flips into an optimist opportunity. Part 3 is a specific forwarder conversation that rearranged our roadmap. Part 4 is how the engineering side of the house has been adapting — including the line we drew for where AI is allowed to touch.
Next → Part 2: Why I stopped being a pessimist about freight tech
— Glenn
