The autonomous robotics market looks a lot like the automotive industry did in the 1940s, when every manufacturer built pretty much everything itself, down to the smallest components. GM used to make its own spark plugs. Over the following decades, Tier 1 players took over huge parts of that stack, and not by being cheaper. They specialized deeply in a handful of components, they pooled R&D costs across dozens of manufacturers who could never have justified that spend alone, and eventually they built certification processes solid enough that switching suppliers stopped being worth the trouble.
We think robotics is heading toward the same kind of moment, just a few decades behind. That's more or less the bet behind Exwayz: get the specialized piece, localization, right enough, and support enough platforms and environments, that teams building robots can spend their engineering time on what actually makes their robot theirs instead of on SLAM.
At some point, every team building a mobile robot hits the same wall: the robot has to know where it is, and not in a rough, most-of-the-time sense. It needs centimeter-level accuracy, continuously, in whatever environment it actually ends up deployed in, which is rarely a clean office floor. A port with cranes swinging overhead. A tunnel where GPS doesn't exist at all. A warehouse where every aisle looks like the last one.
So the team builds its own SLAM stack. Almost always in-house, and almost always because someone assumes it's basically a solved problem by now, maybe a couple of quarters of work for a strong team.
It's essentially never a couple of quarters. And even once something works well enough to ship, the cost doesn't go away, it just changes shape. We'd call this the SLAM tax: a cost every team building its own localization pays, whether or not anyone on the team has ever put a name on it. It rarely shows up as a line item on a budget. It shows up more quietly, as a slipped roadmap, as the senior engineers who never quite rotate off localization a year later, as a team that keeps reorganizing itself around a problem nobody actually set out to own.
Strip away the framing and it's a pretty ordinary cost model. Most teams just never sit down and build it out.
There's the build cost first. Getting a production-grade stack to something you'd actually trust in the field, not in a demo, takes a small team of senior engineers something like a year. Realistically, that's hundreds of thousands of dollars to get an MVP working, and it climbs into the millions once you're scaling across more ODDs.
Then there's maintenance, and this part doesn't really end. New environments show up, new edge cases show up, sensor firmware changes under you. In practice this tends to mean one or two senior engineers stay attached to localization more or less permanently, for as long as the product exists.
There's a lock-in cost too, one that's easy to underestimate early on. Whatever you build gets built around whatever LiDAR you happen to be using today. Switching sensors later, which at scale is often unavoidable, means going back and re-checking assumptions that are by then baked pretty deep into the stack.
And then there's the one that matters most in our experience, which is opportunity cost. Every month an engineer spends on localization is a month they didn't spend on whatever actually makes the robot worth building. SLAM is very rarely the thing that differentiates a robot. It's closer to the toll you pay to get to the part that does.
The instinct is to treat all of this as a one-time cost: build it, amortize it across the fleet, move on.
That's not really how it plays out. The team that built the stack doesn't stay the size it was at launch, because edge cases keep multiplying as the fleet grows and gets deployed into more environments, so the team tends to grow along with it. The debt doesn't get paid down so much as it gets serviced, indefinitely. And the number that actually matters to whoever holds the budget, cost per vehicle, keeps moving as the deployment scales, usually not in the direction people expected when they first signed off on building it.
Most build-versus-buy comparisons get this wrong because they really only model year one. This is a multi-year number, and in our experience it tends to end up bigger, and later, than whatever the team assumed going in.
There's one question that tends to cut through most of this pretty quickly: at your fleet size in year three, what does your SLAM cost per vehicle actually look like, fully loaded?
Most teams haven't run that number. Which, if you think about it, means they've already paid the first cost of the tax without quite realizing it: the cost of not knowing what they're actually spending.
The teams that have done the math are the ones worth having a real conversation with, honestly, because at that point it stops being a question of whether they trust us as a vendor and becomes a question of arithmetic. Is this the fleet size and timeline where building ever catches up to buying? And is that crossover point closer than it looks, or further away than it feels?
We've watched dozens of autonomous trucks run 24/7 across container yards at the Port of Rotterdam, in terrain that's constantly changing, without anyone needing a dedicated localization team on payroll. We've seen a car run GNSS-independent at over 250 km/h on the Abu Dhabi circuit, built by the first French team to ever compete there. We've seen a delivery robot localize itself in the middle of Paris using the same stack that also runs fine in a tunnel with no signal at all.
None of those teams paid the SLAM tax. They paid a license instead, and put their engineering time into whatever actually made their robot theirs.
The real choice is what you want your best engineers spending the next three years on. SLAM, or the thing that only your company can actually build.
We started Exwayz because we think most teams get this call wrong, not because they're wrong about being able to build it themselves, most of them probably could, but because nobody ever really showed them what it costs to do it.
If you haven't run that number for your own fleet, we're glad to run it with you.