The humanoid robot industry shipped over 5,500 units in 2025. Conferences buzzed. Demo videos went viral. Investment decks declared we had entered the humanoid era. But ask a quieter question and the picture shifts: how many of those robots are actually doing useful work?

The answer is uncomfortable. The vast majority of humanoid robots delivered in the past year are sitting in labs, warehouses, and university hallways doing very little. Not because the hardware is broken. Because the software to make them useful barely exists.

This is the humanoid software gap, and it is the single biggest obstacle between the industry and real-world impact.

The Numbers Tell the Story

Unitree alone shipped over 5,500 humanoid robots in 2025, making it the largest humanoid manufacturer by volume. But it is far from the only player. Figure is ramping production of its Figure 02 platform. Tesla continues to iterate on Optimus with plans for factory deployment. Agility Robotics has Digit working in Amazon fulfillment trials. Apptronik is advancing Apollo toward commercial readiness.

By 2027, there will be at least six major humanoid platforms on the market, with combined annual shipments projected in the tens of thousands. The hardware side of the industry has hit an inflection point. Production lines are scaling. Costs are dropping. Lead times are shrinking.

The hardware race is well underway. The software race has barely started.

The Hardware Revolution Is Real

Give credit where it is due: the hardware achievements of the past two years are genuinely impressive. Modern humanoid platforms share a set of capabilities that would have been science fiction five years ago:

The physical platform is ready. You can buy a humanoid robot today that walks, balances, grasps objects, and processes sensor data onboard. The mechanical engineering is not the bottleneck.

The Software Gap

So if the hardware works, why are most robots sitting idle? Because the software layer that translates capable hardware into useful behavior is critically underdeveloped. The problems are systemic:

SDKs Are Sparse and Under-Documented

Most humanoid manufacturers ship an SDK that covers low-level joint control and basic sensor access. Documentation is thin. Example code is minimal. Going from the SDK to a working application requires deep expertise and significant trial-and-error. Developers spend weeks just figuring out the communication protocols before they can write their first useful behavior.

Sim-to-Real Transfer Remains Hard

Training behaviors in simulation before deploying to hardware is the standard approach. But the gap between simulated physics and real-world dynamics is substantial. Policies that work perfectly in MuJoCo or Isaac Sim often fail immediately on hardware. Closing this gap requires careful domain randomization, system identification, and iterative tuning that few teams outside of dedicated research labs have the capacity to do.

No Cross-Platform Standards

Every platform has its own SDK, its own communication protocol, its own model format, and its own control conventions. Code written for a Unitree G1 will not run on a Figure 02. There is no equivalent of POSIX, no hardware abstraction layer, no common API. Building for multiple platforms means building everything twice.

Custom Skills Require Deep Expertise

Teaching a humanoid robot to perform a new task is not like writing a web application. It requires reinforcement learning, dynamics modeling, perception pipeline design, and real-time control engineering. The talent pool with this combination of skills is tiny and concentrated in a handful of companies and research labs.

Most Buyers Do Not Have Robotics Software Teams

The organizations purchasing humanoid robots in 2025 and 2026 are universities, research labs, manufacturing companies, and logistics firms. Most of them do not have in-house robotics software engineers. They buy a robot expecting it to do something, and then discover that making it do that thing is a multi-month software project they are not equipped to execute.

Why This Gap Exists

The software gap is not an accident. It is a natural consequence of how the industry has developed. Hardware companies are, fundamentally, hardware companies. Their engineering talent, their R&D budgets, and their competitive advantage are in mechanical design, actuator development, and manufacturing processes. Software is treated as a means to demonstrate hardware capability, not as a product in its own right.

The humanoid industry today is where the PC industry was in 1981. The hardware works. But the software ecosystem that makes it useful has not been built yet.

The analogy is instructive. IBM shipped the PC. But it took Microsoft, Lotus, WordPerfect, and thousands of application developers to make the PC into something that changed how people worked. The hardware was necessary, but it was the software ecosystem that created the value.

The humanoid industry is waiting for its software ecosystem.

The Emerging Software Ecosystem

Pieces of that ecosystem are starting to form, driven largely by the biggest companies in the space:

This is real progress. But notice what is still missing: the application layer. The infrastructure exists to train and simulate. What does not exist is the library of tested, deployable skills for specific use cases. No one is shipping a package that makes a G1 robot sort lab equipment, or a Digit robot handle warehouse returns, or an R1 robot assist elderly patients.

The foundation models give you a starting point. The simulation tools give you a training environment. But the last mile, turning those tools into working behaviors on specific hardware for specific tasks, is where the gap is widest.

Why It Matters Now

This is not an abstract industry analysis problem. The software gap has concrete economic consequences that are compounding right now:

The window to close the software gap is not indefinite. The industry needs the software layer to mature fast enough to keep pace with hardware deployment, or the hardware companies will find that their growing production capacity is shipping into a market that is losing patience.

What Needs to Happen

The humanoid industry needs a dedicated software services layer: companies and teams whose entire focus is making robots useful after purchase. Not hardware companies with a software team on the side. Not research labs publishing papers. Companies that wake up every morning thinking about how to take a humanoid robot from delivery to deployment.

This means:

The hardware companies cannot do this at scale. It is not their core competency, and it should not be. The research labs will not do it because productionizing software is not what they are built for. The gap has to be filled by a new category of company: the humanoid software services firm.

This is what Habil was built to do.