Every morning for most of my career, I watched the same thing happen. Dispatch would come in at 5 AM — sometimes 4:30 — with yesterday's routes already loaded in the system. By 6 AM, when drivers started showing up for their manifests, the plan was already wrong. A road closure on Henderson Road that came in overnight. A commercial stop that called in a time window change. A driver who called out sick, which meant 22 stops needed to be redistributed across the remaining vehicles before first departure.
And the dispatchers would fix it by hand. Pull up the map. Move stops around. Re-number the sequence in the spreadsheet or the TMS. Print new manifests. Catch the driver before they left the lot.
I watched this happen for six years, at three different operations, and the thing that struck me most wasn't that it was inefficient — I knew that — it was that everyone accepted it as just how dispatch worked. The manual re-planning every morning wasn't seen as a failure of process. It was the process.
What I was doing before this
My background isn't engineering. I came up through operations. I started as an operations analyst at a regional logistics company in Cincinnati right after finishing my degree — a mid-size operation running about 40 routes a day in the greater Cincinnati metro. My job was ostensibly to help build reports and track KPIs, but in practice I spent a lot of time in the dispatch office, which is where the interesting problems were.
Over the following years I moved between a few different roles and companies — a stint at a freight forwarding firm, a couple of years at a Columbus-based carrier that did last-mile distribution for a furniture retailer, and finally a director of operations role at a mid-size regional carrier headquartered on the east side of Columbus. By the time I was in that director role, I had a good handle on operations at multiple levels — I understood how dispatch queues were built, what dispatchers actually needed to do their jobs, where the bottlenecks were, and which problems kept showing up in the same form year after year.
The re-planning problem was the one that showed up everywhere, in every operation I worked in, regardless of size or market or TMS vendor.
The specific moment I couldn't explain away anymore
There wasn't one dramatic incident that made me decide to build Routely. It was more like an accumulation that crossed a threshold. But there's one specific morning I think about when people ask why I did this.
It was a February morning in Columbus — a Tuesday — and I-270 had icing on the outer belt section between the west side and Dublin. Not closed, but severely slowed. We knew about it by 5:45 AM when the traffic reports came in. By 6:30 AM, our dispatch lead had already been on the phone with three drivers, had redrawn parts of four different routes by hand, had printed and re-printed two manifests, and was about 45 minutes behind on getting the remaining 12 drivers out the door.
And I thought: we have a TMS. We have routing software. We have GPS on every vehicle. And the response to a road condition that anyone with a smartphone could see on Waze at 5:45 AM is a person with a marker re-drawing routes on a printed map on a clipboard.
I went back to my office and started a document that I kept returning to for the next eight months. What would a system actually need to do to fix this? Not just optimize routes at the start of the day — anyone could do that — but re-optimize continuously as conditions changed, push updated sequences to drivers without requiring them to pull over and reload a plan, and do it fast enough that the update was useful rather than arriving after the driver had already committed to the old path.
Why the existing tools weren't enough
I want to be fair here. The routing tools I used throughout my career weren't bad products. They solved the problem they were designed to solve: given a set of stops and time windows, generate an efficient initial route. That's genuinely hard to do well, and the good TMS vendors did it reasonably well.
The problem was the design assumption behind all of them: that the planning window happens at the start of the day and the execution window happens after. Build the route at 5 AM; drive it from 7 AM to 5 PM. Any disruption that occurred during execution was a human problem, handled by dispatchers on the phone and drivers making judgment calls.
That assumption might have been reasonable in an era when delivery commitments were loose ("sometime Tuesday") and customer expectations were low. It doesn't hold anymore. Customer expectations for delivery precision have moved significantly over the last several years. Time windows have gotten narrower. Failed delivery attempt rates have real cost and real customer service consequences. The gap between planning-time route quality and end-of-day actual performance matters in ways it didn't before.
I looked at what was available in the market and concluded that the problem I was trying to solve — live re-sequencing fast enough to be operationally useful, pushing updates through a driver app, with constraint awareness of time windows and vehicle capacity — wasn't something I could buy. The tools that existed were built around the static-plan model. I needed something built around the assumption that the plan would change.
Building it with Marcus and Dana
I met Marcus through a mutual contact in the Columbus tech scene in late 2023. He had been working on routing algorithms at a mapping data company and was interested in applying that work to fleet operations specifically — he'd seen the same gap I'd seen from the engineering side. We spent about six weeks going back and forth on technical approach before agreeing that we were solving the same problem from different directions and should just work on it together.
Dana came in a few months later. I'd worked with her briefly years earlier and knew she had the operations depth we needed. Building software that dispatchers and drivers would actually use requires someone who has been in a dispatch office at 5 AM on a bad morning. Dana had. She has an instinct for where workflows break down in practice that I've seen be correct again and again, and she's direct about it in a way that's been essential for keeping us honest about whether what we're building actually helps people in the field or just looks good on a demo.
The three of us built the first working version of Routely out of a spare room in my house in Clintonville. It was rough in the ways that early software is always rough. But the core behavior — ingest a stop manifest, build an optimized sequence, re-sequence against live traffic conditions on a 15-minute cycle, push updates to a driver-facing app — worked from fairly early. Getting from "works" to "works well enough for a real fleet to depend on" took another year of grinding through edge cases and learning things we hadn't anticipated.
What we got wrong early
We over-engineered the routing algorithm and under-engineered the driver app. This is a classic mistake for a team that includes strong technical people and is building in a domain where the algorithmic problem is interesting. The routing engine was genuinely good from early on. The driver app was barely functional for the first six months.
We learned the lesson the hard way: route optimization software is only as good as the last-mile interface. A perfect sequence that a driver ignores because the app is slow or confusing produces worse outcomes than a decent sequence that a driver actually follows. The driver app is not a secondary consideration — it's where the product either works or doesn't.
We also got the onboarding model wrong initially. We assumed that once a carrier decided to use Routely, their dispatchers would figure out the product and their drivers would follow. That assumption didn't account for the trust gap — dispatchers who had run manual operations for years had earned the authority to manage routes the way they managed routes, and a new system that proposed to change that dynamic needed to earn trust, not assume it. Dana has written about what we learned fixing that problem. The short version is: we should have been more thoughtful about change management from day one, not after our first bumpy deployments.
Why Columbus was the right place to build this
Columbus has a genuine logistics ecosystem that doesn't get enough credit. We sit at the intersection of I-70 and I-71, within overnight drive of a substantial fraction of US population. There are real carriers here running real regional distribution operations, not just warehouses. The density of operational expertise in this city — dispatchers, fleet managers, operations people with decades of experience — is higher than most people outside Ohio realize.
Building Routely here meant we were testing against real-world complexity from the start. Columbus traffic is genuinely variable — the outer belt congestion around the I-270 interchange behaves differently from I-71 north, which behaves differently from the downtown core near I-670. If we could handle the routing complexity of a Columbus metro operation well, we had a model that would generalize to similar mid-size metro markets.
I also just live here and know it. Building software for a market you've worked in for years, where you know the streets and the operations and the people, is an advantage I didn't want to give up by moving somewhere with a more obvious startup cluster.
What this is actually about
I didn't build Routely to compete with large TMS vendors or to be a general-purpose logistics platform. I built it because dispatchers I worked with for six years were spending hours every morning doing something that a well-designed system should handle automatically — and the system I needed didn't exist.
That's still what we're building toward. Not the broadest possible logistics platform, but the tool that makes dispatch professionals' mornings less manual and drivers' routes less wrong by noon. We know this problem in ways that come from years inside it. That's the only real edge we have, and it's the one we're trying to make count.
