Three friends from Texas left a video startup to build the plumbing robots run on. Their bet: the hardest problem in robotics is not the motor - it is the software you keep changing.
A robot is not one machine. It is a moving argument between hardware, firmware, sensors, and software, and the argument is settled by a set of numbers in a file. Change the wrong number and the robot drives into a wall. Change nothing and it never gets better. Every robotics company in the world lives inside that tension, and most of them handle it the same clumsy way: an engineer opens a terminal, connects to a machine one at a time, and hopes. Miru, a San Francisco startup out of Y Combinator's Summer 2024 batch, was built on the belief that this is a solvable problem, and that solving it well is a business.
The one-line pitch is disarmingly simple: updating software on thousands of devices should be as easy as pushing a change to GitHub. Web engineers have had that luxury for a decade. They commit code, a pipeline builds it, and it ships to every server without anyone touching a machine by hand. Robotics teams get none of that. They ship physical products into warehouses, farms, sidewalks, and factory floors, and then they discover that the tooling to keep those products current does not really exist. So they build it themselves, badly, over and over.
Updating software on thousands of devices is as easy as pushing a change to GitHub.
Miru's founders wrote an essay early on with a title that doubles as a thesis: robotics config management is a mess. The mess has a specific shape. Configurations in robotics are usually loose files - YAML or JSON - with no built-in validation, so a type mismatch that would be caught instantly in real code instead becomes a runtime crash on a machine that is already out in the field. Code and config schemas have to evolve together, and when they drift apart the robot is left in an unsafe state. Layer on conditional logic, fleet-by-fleet customization, and the competing demands of engineers, field operators, and compliance teams, and a task that sounds administrative becomes one of the hardest things a robotics company does.
The cost of that mess is not abstract. In its launch, Miru argued that companies without real deployment tooling end up dedicating more than half their engineering staff to building and babysitting internal systems - people who were hired to make robots smarter instead maintaining the scaffolding that ships the software. That is the number that should make a founder wince.
There is a reason this problem is specific to robots and not, say, phones or laptops. A consumer device runs one operating system that a large vendor updates on a predictable schedule. A robot is a bespoke stack: a particular sensor array, a specific motor controller, a firmware build, and a pile of application code that all have to agree on the same set of parameters at the same moment. When any layer changes, the configuration underneath it usually has to change too. The result is that config is not a side file in robotics - it is the connective tissue holding a fragile system together, and it fails in ways that are hard to see until a machine is already misbehaving in the physical world.
Strip away the framing and Miru is three things working together. There is a cloud platform that automates the build, staging, and deployment of software to fleets of devices, triggered directly by a push to a GitHub repository. There is a config management layer where teams define their configurations against schemas that enforce structure and constraints, with validation hooks that check every change is safe and compatible before it is allowed anywhere near a robot. And there is the Miru Agent, a lightweight systemd service that runs on each device and uses a pull-based model to fetch the correct configuration from the cloud.
The agent is the part that reveals how the company thinks. Robots do not live in data centers. They lose signal, they reboot at inconvenient moments, they run on networks that would embarrass a coffee shop. So the agent caches the most recent config locally and is built to survive all of it. Instead of the cloud pushing updates and praying they land, each device reaches out, pulls what it should be running, and keeps a known-good copy in its pocket. It is a small design decision that quietly encodes a hard-won rule of distributed systems: design for the failure, not the happy path.
For developers, none of this is trapped behind a dashboard. Miru is deliberately developer-first: everything is reachable through APIs, webhooks, SDKs, and Git integration, so a team can wire configuration and deployment into whatever CI/CD pipeline they already run. Getting started is a single command on an Ubuntu-based device. The dashboard exists for the humans who need to see which version is running where, but the machinery underneath is meant to be automated. That split matters: engineers get an API surface they can script against, while operators and less technical stakeholders get a view they can read without breaking anything. Serving both audiences from one system is part of what makes robotics config hard, and it is exactly the seam Miru is trying to own.
Miru is the work of three University of Texas at Austin graduates who had already built a company together before this one. Armel Talla, the CEO, studied computer science and mathematics and spent time on internal tools at Google and YouTube. Vedant Nair, the COO, came from the business and go-to-market side, with consulting stints at Bain & Co. and EY-Parthenon. Benjamin Smidt, the CTO, has an electrical and computer engineering background with mechanical engineering roots, and had built production AI infrastructure on Kubernetes.
Their previous venture was Clips AI, a tool that automatically chopped long videos into short clips. They scaled it to roughly 7,000 monthly active users in three months, and then they did the harder thing: they walked away from a consumer product with traction to go build unglamorous infrastructure for robots. There is a certain honesty in that choice. The plumbing rarely trends. It also rarely goes out of style.
The mix of backgrounds is worth pausing on, because it maps neatly onto what an infrastructure company actually needs. Talla's time inside Google and YouTube was spent on internal tools, which is precisely the kind of work Miru is now selling to everyone else. Smidt's hardware roots mean the team understands the device end of the problem, not just the cloud. And Nair's go-to-market experience covers the part that trips up most deeply technical founders: explaining an unglamorous product clearly enough that a busy engineering lead will try it. A company selling to robotics teams has to speak the language of the people wrestling with the terminal at midnight, and this is a team that has been in that chair.
Every configuration change in Miru is validated before it can affect a robot.
Miru is not the only way to move software onto devices. General-purpose fleet and over-the-air tools like Balena, Mender, and Memfault exist, as do the heavyweight cloud offerings such as AWS IoT Greengrass and Azure IoT. But the true incumbent - the thing Miru is really displacing - is the homegrown deploy script. It is the internal tool nobody wants to own, the one held together by a single engineer's memory and a folder of shell files. That is the competitor most robotics teams actually have, and it is a good one to be replacing, because everybody quietly hates it.
| Approach | What it optimizes for | The gap Miru targets |
|---|---|---|
| Homegrown scripts | Full control, zero license cost | Eats engineering time; brittle at scale |
| General OTA tools | Shipping any device firmware | Thin on robotics config validation |
| Cloud IoT suites | Broad device management | Heavy, not robotics-specific |
| Miru | Validated config & deploy for robots | Schemas, versioning, resilient agent |
The wager underneath the company is a read on timing. Everyone is racing to build the robots themselves - humanoids, delivery bots, agricultural machines, warehouse arms. Miru is selling the pickaxes. As physical automation scales, its founders bet the bottleneck moves off the hardware and onto the software that keeps thousands of machines coherent in the field. If they are right, the deployment layer becomes something every robotics company needs and almost none of them want to build. That is a comfortable place to stand.
For a robotics team, the practical promise is narrow and useful. Define your configs once, with schemas that catch mistakes before they ship. Roll a change out to one robot, a subset, or the whole fleet, and track exactly which version is running where. When something goes wrong, roll back rather than dispatch someone with a laptop and a USB cable. Let field operators adjust the parameters they are allowed to touch without handing them the keys to the whole system. And do all of it through the same Git workflow the engineers already know, so deployment stops being a separate discipline and becomes part of how the team already works.
Miru is early, and it is small - a founding team, a seed-stage company, a product still finding the shape of its market. It has not published a customer roster or revenue, and it would be a stretch to call the category won. But the problem it picked is real, specific, and unloved, and the people who feel it most are exactly the ones who will recognize the pitch on sight. In a field obsessed with what robots can do, Miru is focused on something quieter: making sure the software inside them can be changed without fear.