TL;DR
In talking to many physical AI companies, a pattern has emerged: there are two types of robotics founders now. Hardware-first and software-first. And software-first are growing. They don't just build differently, they think differently. The gap between them is where a new field of opportunities can come from.
If you are interested in building for physical AI, you should understand this new and growing persona: the software-first robotics founder.
We talk to many robotics companies and I am now convinced there are two types of founders. The difference is not what they build, it is how they think.
- Hardware-first founders
- Software-first founders
This distinction sometimes matters more than consumer vs industrial, or small vs large. And the growing wave is clearly software-first. Curiously, at least one founder said they found robotics exciting after Cursor/Claude/etc made traditional SaaS boring.
Chris Dixon has a story about Stripe. When they were raising money, investors asked: “who are your customers?”
The answer was: “they don't exist yet.”
That's what this feels like.
Software-First Founders (The New Wave)
A lot of software engineers are entering robotics for the first time. They are not bringing robotics assumptions with them. They are bringing expectations from software.
You can see this clearly when you ask about simulation.
Hardware-first leaders tend to say something like: “it is just one tool among many, the real world matters more, and yes it is painful but you get used to it after a few months.”
Software-first founders react very differently. They say, “simulation is central. It is not just for training. It is for demos, for sales, for iterating on ideas. And the friction feels completely unreasonable.”
I hear things like: “why is there no strong prompt-to-simulation yet?”, “why would I spend three months learning this?”, and “why is deploying MuJoCo to the cloud this hard?” We ran into this ourselves and wrote about it here: Deploying MuJoCo on Azure ML
To them, simulation is not a niche tool. It is the main interface to building. This is not just about MuJoCo. It shows up anywhere the stack assumes you are willing to spend weeks wiring things together.
Different Problems
When I ask software-first founders what their biggest problems are, I hear the same patterns over and over:
1. Recruiting Hardware Talent
“Diego, I have no idea how to hire mechanical engineers, so I just used AI to create interview questions, source candidates, etc…”
A lot of them simply do not know how to hire or evaluate great mechanical or electrical engineers. I have heard people say they used ChatGPT to come up with interview questions, or that they ended up hiring someone remote because they had no local network. A surprisingly common pattern is software teams in SF, Austin, or NYC hiring mechanical engineers in the Midwest, where easy access to CNC shops and broader manufacturing infrastructure exists.
2. Distribution Outside Integrators
“I spend more time thinking of distribution channels than mechanics”
There is a real hunger to find channels beyond traditional system integrators. Social media, content, direct sales, anything that lets them bypass the traditional path.
3. Data Labeling Is Still Too Manual
“I was genuinely surprised how dirty the data is, there is no common crawl like LLMs. I spent lots of energy creating mini models to clean up and classify data just so I can train the real model”
People are downloading models from Hugging Face, plugging them into robots, and then realizing they are still spending huge amounts of time labeling and cleaning data. It feels ridiculous that this is still so manual in 2026.
4. Sim-to-Real Is Reframed, Not Solved
“The sim to real gap doesn't affect me… I just take it for granted and look for use cases where 95% is good enough (clearly not self driving) and I go crazy ham on the randomization”
Instead of trying to solve sim-to-real directly, they pick use cases where the gap does not matter. If something works 95% of the time, they choose problems where 95% is still useful.
5. Tooling Feels Powerful but Painful
“I asked a mechanical engineer friend how I can do something in CAD, they told me yeah its painful but I should get it in 3 months. 3 months?! I was shocked how comfortable he was with status quo. I needed something in 3 days.”
Everything technically works, but it feels like AWS: powerful, but heavy. There is no equivalent of Vercel where things are simple, fast, and pleasant.
6. Default to Delegation or APIs
“I don't need to own everything… the more I can API or SaaS or Agentify away the better. I am not obsessed with vertical integration like some of my fellow founders. I am more obsessed with iteration, validation and real market demand first”
If something is too hard to do themselves, their instinct is to either find an API or offload it entirely, rather than go deep and learn it.
7. Time-to-Demo Pressure
“I need to have a demo today, tomorrow, close the sale, do things that don't scale”
There is constant pressure to get something working end-to-end quickly. Not perfect, just working, so it can be shown, sold, or built on top of.
Software-first founders don't try to understand the whole system. They try to get around it.
What Surprised Them
These founders also run into a few things that don't match their expectations:
1. Suppliers Are Not a Layer, They Are the Product
Many are surprised that manufacturing and supplier relationships are not something you abstract away. They are a core competency, as Rui Xu describes here.
2. The AI Stack Is Slightly Wrong for Robotics
The AI tooling ecosystem has spent the last three years optimizing for LLMs and image generation: training frameworks, evaluation tools, deployment pipelines, cloud platforms. Robotics workflows have different requirements (policies that run in closed loops, evaluation through rollouts, contact-rich physics) and the tooling just hasn't caught up. Nothing is broken exactly, but nothing fits cleanly either.
3. Data Is Crowded and Still Unsolved
There is an open secret in robotics: many software people enter the space to build “data for robotics” companies. Almost every large robotics company we talked to said data is a huge industry-wide problem over the next 18 months. But robotics data is embodied, task-specific, hardware-dependent, and expensive to collect. There are a lot of interesting players attacking this from different angles, but nobody has cracked it yet.
4. Selling Robots Is Much Harder Than Selling Software
Distribution, sales cycles, and trust look very different. This surprises almost everyone coming from software, more than they initially expected.
What This Unlocks
Most robotics tools were not built for this kind of founder.
The new wave of founders does not want to spend weeks getting a simulator running or months understanding a stack before they can do anything useful. They expect things to work quickly, to be abstracted, and to be self-serve.
Here are some ideas that come from what people have described:
- Embodied data validation
“I just spent a week gathering real-world data for my robot – is it actually useful?” - Streamlined design-to-manufacture pipeline
“Design me a robot via prompt and show me the cost to build it with real off-the-shelf parts (not some Midjourney nonsense), test multiple policies, and run it in simulation. Iterate until it works.”
None of these are new ideas in isolation, but the urgency feels different. People are not just noticing the pain, they are frustrated by it.
If you are working on any of these problems (or want to), we'd love to meet you to brainstorm, promote, or connect you with like-minded folks. Book a time to chat with us.
