Most freight forwarders didn’t sign up to be a technology company. They signed up to move freight. But that distinction is getting harder to maintain, and ignoring it is starting to cost real money.
The question used to be which TMS to buy. That question has split in two: which specialized platforms to plug into, and which small internal tools are worth building in-house. The forwarders pulling ahead are answering both.
Why the TMS you’re paying for probably wasn’t built for you
Most TMS platforms were built in the early 2000s. Before the iPhone, before cloud computing was standard, before APIs were a given. The underlying architecture reflects those constraints.
What that means in practice: VPN dependencies, no live carrier data, manual re-entry across systems that don’t communicate. One freight forwarder we read about described a three-day turnaround just to pull a standard report. Three days. And they’d stopped noticing.
The cost isn’t just time. Mid-market TMS tools run €350 to €2,000+ per month. Enterprise implementations (CargoWise tier) typically end up costing three to five times the advertised price once integration, customization, and data migration are factored in. You get quoted €50,000 a year and land at €200,000 before processing a single shipment.
The compounding problem: once you’re locked in on architecture from fifteen years ago, every workaround you build is built on top of it. The platform isn’t the answer. The architecture is the problem.
What AI coding actually means for a freight forwarder
In February 2025, AI researcher Andrej Karpathy coined the term “vibe coding”: describing what you want in plain language and letting AI write the code. Collins Dictionary made it Word of the Year. That tells you how fast this spread beyond tech circles.
For a freight forwarder, AI coding matters in two ways at once.
On the vendor side, the specialized platforms you buy from are shipping faster than at any point in software history. AI-native vendors push features weekly that legacy TMS providers would have planned for a quarterly release. The moat compounds: a vendor who deeply understands freight and ships with AI is now pulling decisively away from a vendor who deeply understands freight and ships through a 2010 release cycle. Pick vendors who are using AI natively. That choice matters more this year than last year, and more next year than this one.
On the in-house side, the same tooling lets an ops person close the small gaps no vendor will ever fill. A quoting tool that matches your actual pricing logic. A carrier scorecard your ops team has been doing in Excel. A booking confirmation workflow. An internal KPI dashboard. These are tools unique to how you operate. No vendor will build them for you, because every forwarder’s workflow is different.
Dockflow, an AI-native container visibility platform for freight forwarders, is one example of what this looks like on the vendor side: the same AI tooling that lets a small ops team build internal scorecards is letting specialized vendors out-ship legacy TMS by a factor of ten.
If you’re on Microsoft 365 (most European forwarders are), you already have Power Apps and Power Automate for the in-house pieces. That’s the combination the forwarders pulling ahead actually run on: specialist vendors for the heavy lifting, AI-assisted internal tools for the bespoke pieces.
Why specialists win
AI coding tools are powerful precisely because they compound in the hands of teams with deep domain context.
That’s the part of this story that doesn’t get told enough. The headlines focus on AI writing code. The reality is that AI writes code dramatically better when the human directing it deeply understands the problem. For a domain like freight, that context lives with specialized vendors and with the ops people who do the work: carrier integrations, ETA training data, real-time port and terminal feeds, customs logic.
This is why the gap between AI-native specialists and legacy TMS is structural, not temporary. A vendor who lives in carrier integrations and ships with AI compounds advantages every quarter. A legacy TMS bolting an AI feature onto a 2005 architecture is doing something different and slower. Same words, different outcomes.
Bain’s 2025 research makes the same point from another angle: AI paired with genuine process transformation produces 25-30% productivity gains. Without the process transformation, you get 10-15%. The tool doesn’t do the work on its own. You still have to know what you’re building and why. Specialists know.
The data moat most forwarders are giving away
Here’s what doesn’t get said enough: data ownership compounds.
When you run on a legacy third-party TMS, the data model is theirs. The analytics are built for the average use case. When you pick vendors who give you data access, and build the bespoke pieces yourself, the data is yours either way. You can connect it to anything. You can run your own models on it. Over time, that compounds.
Flexport is the extreme example. They’ve automated 50% of operational workflows and are targeting 80-90%. They’ve built a proprietary data flywheel that traditional forwarders can’t replicate. The data lives in Flexport’s system, structured the way Flexport chose to structure it.
One independent freight forwarder won back a €25M account through a digitized customer portal. Not through a better shipping network. Not through better rates. The customer could track shipments, get reports, share data. That’s it. A targeted tool that changed what the customer could see.
This is why data ownership matters from day one. Where does the data live? Can you query it? Can you connect it to your next tool? Every vendor you sign with, and every tool you build, should answer those questions before you commit.
What to actually do this week
Five takeaways from the research:
Audit your TMS honestly. Not as a feature checklist. Look at where your team is doing manual re-entry, copy-pasting between systems, waiting three days for a report. That’s a tool problem you’ve been paying for.
Build the unique tool, replace the generic one. Not either/or. The genuinely bespoke piece your ops team needs (your quoting logic, your scorecard) is the one to build in-house. The generic legacy piece (the report builder, the visibility module) is the one to replace with a specialized vendor.
Don’t build what specialists have already solved. Container tracking requires hundreds of carrier integrations, years of ETA training data, real-time feeds from ports and terminals. That’s what Dockflow is for. Build the things unique to your operation. Buy the infrastructure that takes a specialist team to maintain.
Think about data ownership from the start. With every vendor and every internal tool. Where does it live? Can you connect it to the next one?
The window is open now. In two or three years, the forwarders running on AI-native specialists plus a small set of bespoke tools will have data assets and automation infrastructure that are genuinely hard to replicate. The forwarders still on legacy TMS won’t catch up by buying a newer version of the same architecture.
The market is already splitting. Digital freight forwarding is growing at 18.8% per year. The overall market: 5.7%. That gap is structural. The companies compounding a software and data advantage now are not going to slow down later.
You don’t need to become a software company. You need to pick vendors who already are one, and build the few things only you can build.
Frequently Asked Questions
Can a freight forwarder really build software without a development team? For scoped internal tools, yes. AI coding tools like GitHub Copilot or Microsoft Power Apps let someone who understands the problem describe it in plain language and generate working code. The constraint is scope: this works for a quoting tool or a carrier scorecard, the bespoke pieces no vendor will ever build for you. It doesn’t replace specialized platforms for visibility, ETA prediction, or carrier integrations. The combination is what works.
What’s the difference between Level 1 and Level 4 AI adoption in freight forwarding? Level 1 is using AI to draft emails and think through decisions. No operational change. Level 4 is AI as the system: autonomous agents running workflows, your team handling exceptions and strategy. Most forwarders are at Level 1-2. The jump isn’t one leap. It’s a series of scoped tools and AI-native vendors that compound over time.
What should freight forwarders build vs. buy? Build what’s unique to how you operate: pricing logic, carrier scorecards, internal reporting dashboards, document routing workflows. Buy what requires specialist infrastructure: container visibility, ETA prediction, port and terminal data feeds, customs systems, carrier integrations. Mixing these up wastes time and money in both directions.
How do I start without knowing where to begin? Start with two audits. One: which of your current vendors are AI-native versus running 2005 architecture. Two: which of your manual Excel workflows are unique enough that no vendor will ever build them for you. The first list tells you what to replace. The second tells you what to build.
