I believe that companies that matter in the physical AI space in the next decade will be vertically integrated.
Owning important parts of your system and having scalable manufacturing for the hardware are the key elements of success. The reasoning is simple — today’s AI models have collapsed the cost of the easy part. A capable person can now assemble off-the-shelf components into a working robot fast, avoiding the costly pitfalls that used to take years to learn. But that is exactly why assembly is no longer an advantage: when anyone can build the mediocre version quickly, the only durable edge is owning the parts that can’t be bought off a shelf.
I can see it in drones: you can get an NDAA-compliant frame, add the necessary off-the-shelf modules and sensors, all within the frame’s payload weight tolerance, and you’ve got a “product.” It will be mediocre, because the frame is optimized for a general use case, and the off-the-shelf components and mounting carry excessive weight, have weird power requirements, and are positioned where you have room rather than where it is optimal for them. Connectivity will also be sub-optimal, with lots of compromises.
You can go one step further and build a much better drone from off-the-shelf parts. You can pick components that are compatible and integrated more tightly together, you can build custom mounting and optimize the frame and propulsion to better serve the needs of the product that you are building. The same goes for the software running on the drone: don’t take just what’s installed on the flight controller and ESCs, but push past that and optimize it for the use case. This is the path we are taking, and every layer we choose to own becomes the foundation for the next one.
Now let’s look at the problem from the angles that matter for a startup — iteration speed, unit economics, reliability and accountability, and the defensibility they add up to.
Iteration speed
This one is counterintuitive. People assume buying off-the-shelf is faster. It is — on day one. It gets slower every day after that, as you scale, expand capabilities, and change features in response to customer feedback.
Owning the stack inverts the curve: slow to start, but it pays off later in the game. Once the layers are yours, you can change any of them fast — push a firmware change, tune a control loop, expose a new telemetry channel, retrain the inference model and deploy. On someone else’s stack, every one of those moves becomes a support ticket, a vendor roadmap conversation, or a workaround you maintain forever.
I learned this the hard way at companies I worked at before. We had already validated the idea, but we were unclear about the scale. We shipped something off-the-shelf and hit all kinds of issues. The supply chain was running well behind demand, and the vendor was slow to react and ramp production. By the time we were past 5k units, we had learned all the problems of the product at that scale — problems the supplier did not even know about. Our reliability numbers were in the red. The engineering support coming out of our team was far larger than the effort it would have taken to add new features, and the company absorbed all of those costs, plus some reputational damage. The next generation was a clean-sheet design — and it was a success story.
That’s the pattern I’m building from. Off-the-shelf is the right first move when you’re still hunting for the idea — if it isn’t validated, the fastest path wins, every time. But we’re past that. We’ve seen the traction and the need, which is exactly why we’re paying the integration tax now, before the seams show, instead of after.
Unit economics
No doubt, historically, setting up production and testing of a physical product required a lot of capital, and that drove up the unit cost at low volumes. We have all heard “hardware is hard” before. But what I’m seeing now is that manufacturing is evolving just as fast — more automation at every level: machine, line, factory, warehouse — making the whole process much easier to set up and scale as demand for the product grows. This has had a real positive impact on the cost of low-volume production.
There is a point on the product’s scale curve where the margins of a vertically integrated product beat off-the-shelf. For drones, with a gradual approach, I think that point is far lower than most people would believe — low enough that it changes the build-vs-buy decision much earlier than the industry assumes.
It sounds implausible until you look at the stack. Most of it is already solved: the motors and props, the microcontrollers and the flight controller, the AI inference module, the cells and the BMS — each has only a handful of serious vendors, mature reference designs, and steady year-over-year gains. You lean on them where it makes sense. What you own is the part that is specific to the use case — above all the mechanical design of the airframe, optimized around those components rather than the other way around. The leverage isn’t in any single part; it’s in how you compose and cost the whole. The secret sauce is making that work at low volume — and I believe I have found one.
Reliability and accountability
This is the lens where vertical integration wins by a mile — and it is the one that matters most for the customer we are building for.
A vendor optimizes for the median customer. That is the rational thing for them to do: serve as many use cases as possible, de-risk the business, survive every market condition. But it means your edge cases — the ones that show up at 2 a.m. on a 911 call, in bad weather, at the edge of the link — are exactly the ones they have the least incentive to harden. You inherit reliability tuned for the average mission, not for yours.
And when something does fail, a black box fails you twice. You cannot debug it. You cannot fix it on your timeline — you file a ticket and wait on someone else’s release cadence. And you cannot explain it. “The vendor’s SDK had a bug” is not an acceptable answer to a city council reviewing a missed call, and “the autopilot did something we don’t fully understand” is not an answer at all. If you cannot trace a failure to a line you wrote, you do not own your product — you are renting it, and renting your accountability with it.
When you own the stack, the failure mode is yours to design for, the fix is yours to ship in hours, and the explanation is yours to give. You can stand behind the system — and certify it, if the deployment demands it — because you can see all the way down. In a mission-critical deployment that is not a nice-to-have. It is the whole job.
Defensibility
This is what the first three add up to. Iteration speed, unit economics, reliability — each is an advantage on its own. Owned together, they compound. You ship faster than the integrator, at a better margin than the assembler, with reliability neither can match — and every turn of that loop widens the gap instead of closing it.
It starts with people. A vertically integrated system requires engineers who can move fluently between mechanical, electrical, firmware, and software — all in the context of drones. Those people are rare, and working with them is one of the real privileges of building this. But the moat isn’t any single hire; it’s the team that holds all of those disciplines together. You cannot assemble that overnight, and you cannot fake it in a pitch.
Then it compounds through data. When you own the stack end to end — the airframe, the firmware, the inference model, the cloud — you own the feedback loop too. Every simulation cycle and every unit in the field feeds improvements in the design, the software, and the models. A competitor sitting on someone else’s hardware cannot close that loop: the data they need lives behind a vendor’s API, in a format they do not control, on a release cadence they do not set. We get a flywheel. They get a roadmap request.
A software layer on commodity hardware does not have this. It can be replicated in months — I have watched it happen. I have watched companies that thought their moat was their app discover that their moat was a thin sheet of glass.
Real defensibility in physical AI is not a clever algorithm or a single hire. It is the accumulated weight of a thousand small decisions across a hundred subsystems — decisions nobody else can see, and that even we only understand because we made them. That weight does not get easier to copy as we grow. It gets heavier. The lead compounds.
The company we are building
I’m a strong believer that vertically integrated solutions will win as the market matures. As the technology advances and the cost of development keeps coming down, more and more companies will operate this way — it will stop being the hard path and start being the obvious one.
We are choosing it early, while it is still hard. It is slow, it is capital-intensive, and it demands a team that is difficult to assemble and harder to keep. But that difficulty is the point: it is the only way to be fast enough, cheap enough, reliable enough, and defensible enough at the same time — and the only moat that compounds instead of eroding.
So we are building the whole thing, end to end. Our own stack, not someone else’s.