I've been quiet. Here's what we've been building.

I've been quiet.

This newsletter has been sitting untouched for longer than I'm proud of. It's not that I ran out of things to say. The last few months have been one of those stretches where the right move is to put your head down and build. And candidly, I've been spending more time writing for our company accounts than for my own.

So here's the overdue version. What we've been working on, what changed recently, and why I'm more optimistic than I've been in a while.

A week in Chicago that changed how I think about building

Last week we wrapped a company offsite in Chicago. Most of the team in one room for a few days.

If you've run a distributed team through a hard stretch, you know the feeling. Everyone is working. Everyone is busy. And it's still too easy to drift slightly out of sync. Priorities blur. Small misunderstandings compound. You lose hours re-explaining things you thought were already settled.

The fastest fix I know is to get the right people in the same room, get crisp on what matters, and then build. That's what we did.

The contrast with our last hackathon, about a year and a half ago, was stark. Back then we had roughly one engineer per team and everyone else huddled around waiting for code to land.

This time, non-engineering teammates were in Claude, Claude Design, and Figma building front ends and workflows off real operator experience. These are people who have actually moved freight. Engineers picked those up and implemented them with the right structure and taste.

A few ideas got far enough that they're turning into roadmap items. Others stayed prototypes, but they answered "is this even worth building?" in a day instead of a month.

Here's why that matters beyond one good week. Building product used to mean engineers translated everyone else's intent into something real. Operators could give feedback, write a spec, or draw boxes. They couldn't build. So engineers became the translation layer, operators became inputs, and the speed of the whole company was capped by how fast translation could happen.

Last week, operators turned their own ideas into front-end designs an engineer could run with, instead of trying to word-vomit a concept in a 30-minute Zoom call. That's a different company.

The thing we've believed since day one

Our vision hasn't changed. Logistics should be an integrated, automated experience, not a patchwork of portals, spreadsheets, phone calls, WhatsApp messages, and "did that carrier pick up the load?" anxiety.

At the core, one thing has to happen reliably: freight moves on the right trucks, with the right carriers, at the right rates.

That sounds obvious. In practice it's still weirdly rare. A lot of the software in freight today is a nicer place to store the same manual work. It doesn't remove steps. It doesn't change who has to chase who. It doesn't make outcomes more reliable.

Why Mexico, and why we don't stop there

People still ask me why Mexico. The honest answer is that it's where the pain is concentrated, where the systems are most broken, and where we've earned the right to have an opinion.

Mexico freight, cross-border and domestic, forces you to deal with everything that makes freight hard. More complexity. More failure modes. More compliance and communication overhead. Higher stakes when something goes wrong.

And it isn't one problem. Different border crossings. Different carrier behaviors. Different lead times. Different compliance needs. Lanes where you find capacity easily, and lanes where you post and get silence.

That's exactly why I'm bullish on solving it. If you can build something that makes Mexico feel simple, you end up making the rest of North America feel better too. Mexico is where we started because it's the best place to prove we're real. It was never the ceiling.

What we've been heads-down on

The last few months have mostly been us saying no to a lot of tempting things and going all-in on four bets.

1. TMS integrations

We've been aggressively integrating with the core off-the-shelf TMSs that most of our customers already run. We'll be announcing those soon.

Without integrations, every marketplace becomes yet another tool. And in freight, yet another tool dies. The best brokers already have a system. They already have workflows. They already have a carrier rep team that knows where the bodies are buried. Ask them to re-enter the same load somewhere new and you're fighting gravity.

Integrations change the shape of the product. Freight flows from the system of record into Cargado without copy/paste. The team sees outcomes without extra steps. You can automate the parts that should be automated.

The boring part is the part that matters. It isn't enough to integrate once. It has to be stable, handle the edge cases, and be owned by someone.

To give a feel for what edge cases look like in freight software:

• The same lane gets written five different ways depending on who typed it.

• One customer calls it Reefer, another calls it temp controlled, and a third buries the requirement in a notes field nobody parses.

• The real workflow is rarely post and wait. It's post, get a bid, find out the pickup time moved, reprice, re-confirm, then book.

If the integration can't survive the messy version of reality, people stop trusting it. And once trust is gone, the team goes back to the manual workaround.

2. Automated coverage

This is the one I'm most excited about, because it's real.

We recently hit the point where we're actually automating coverage for one of our customers, and we'll expand that to more shortly.

Let me make it concrete. A broker's version of coverage was never "posting a load." Coverage is the whole chain: a load exists, it gets priced, it gets in front of the right carriers, someone commits, you book it, you get the information you need to execute, you confirm and move on. What we're building is a path where that sequence is increasingly software-driven instead of human-driven.

If you've ever lived in the world of covering freight, you know how big a deal it is to make that sequence reliable.

One thing I've learned the hard way in logistics: the part that kills you isn't finding a carrier. It's everything around it. The back-and-forth. The missed details. Who has the right phone number. The spreadsheet that's technically shared but nobody trusts.

So a lot of our focus is on the workflow after the match. Truck, trailer and driver info. A clean handoff to operations. Clarity on whether the carrier is actually confirmed. A paper trail that doesn't live in five different inboxes. That's the stuff brokers end up building spreadsheets for, and it's the difference between "we matched" and "the load actually moved."

3. Market rates

The other thing I should have been writing about more is our market rates data.

This might be the most misunderstood part of what we do, because people assume market rates is a nice-to-have chart. What it actually does is force clarity. If you don't know what market is doing, every pricing decision turns into a debate. The loudest person wins. Or the most risk-averse person wins. Or you default to whatever you did last time.

Benchmarking is the one that changes internal behavior the most. If you're managing a team, you want to know whether a rep is consistently pricing above market because the freight is genuinely hard, or because the pricing muscle memory drifted. Those are very different coaching conversations.

What's been most interesting to me is that the use case is basically the same whether you're a smaller operator trying to price confidently, or one of the biggest brokers in the country trying to enforce pricing discipline across a huge book. The difference is scale. The job is identical.

4. Scaling the supply network

Coverage only works if there's real supply. We've been building a more scalable way to add substantially more carrier supply to the network.

I'm not going to over-index on details here, because this is a place where the work matters more than the talking. The goal is simple: more quality carriers, responding faster, on the right freight.

You can't market your way out of a supply problem. You have to build your way out of it. And building here doesn't just mean onboarding more carriers. It means making sure the right carriers actually see the right freight, at the right time, in a way that fits how carriers work. If the experience is noisy, good carriers tune you out. If it's clean, they come back.

How we're running the company now

The other big shift is internal. AI is dramatically different than it was even a year ago, and we've leaned into that hard.

Notion sits at the core of the business as our company brain, where most of our context lives, and we've connected it to basically everything. We use Claude Code and ChatGPT throughout the business, we run Notion Agents across the org, and I've added Grok bots to my daily routine.

I've also used these tools personally to take on a lot of operational work I previously had other people doing. Now it's a prompt. Or an automation. Or a loop that's already running.

The offsite was a forcing function for all of it. Watching non-engineering teammates prototype real workflows, watching engineers implement quickly, watching teams make decisions in the room. It made obvious that this is becoming a core way we work rather than a side tool.

The best part of the week wasn't any single feature. It was watching a much faster loop take hold, and that loop is what I've been chasing for a long time.

Where we're at

I want this industry to have a better experience. That's the whole thing.

We're a strong team. We have control over our destiny. And we're building on our own timeline as we keep iterating.

If you've been following along and wondering where I went, that's where. More soon.

One question I'd genuinely love input on: what's the most painful part of coverage for you today? The sourcing, the trust, the rate volatility, the ops overhead, or something else? Hit reply, I read them all.