.png){kind=small}
Feb 26, 2025
Robots are no longer confined to research labs—they’re expanding their footprint in nearly every industry. From space delivery to food delivery, underwater research to public safety, warehouses to malls, the era of robotics is here.
Big players are moving fast. Figure recently announced plans to ship 100,000 humanoid robots in the next four years. Nauticus Robotics is scaling its research focused on underwater autonomous robotic systems. NVIDIA just unveiled Cosmos, a platform processing 9000T tokens, enabling startups to bring modern AI capabilities to the physical world—beyond 2D screens—accelerating the pace of innovation in robotics.
While a lot is being done to accelerate the adoption of robots across different facets of our lives, there are known risks in this space that frequently catapult promising robotics startups into resource-constrained mode—eventually shattering the dreams of both team members and founders.
It’s an emotional journey, especially when you know you have the right product, but the market just isn’t ready.
Every robotics startup goes through three core phases:
Early adoption and growth—where everything feels possible.
The accelerated resource drain—rapid loss of capital, time, and talent
The survival phase—where, despite the best efforts of teams, each day feels like an uphill battle against time. This is where you will learn a ton of lessons that will most likely shape the trajectory of your robotics startup.
We learned some of these lessons the hard-way a few years ago in Silicon Valley. Around 2018, after having designed mission-critical systems for government agencies in the U.S., U.K. and Netherlands during my time at Motorola, I started reading voraciously about robotics, building 2WD robots, studying ROS (Robot Operating System) amongst other things. During that time, I was fortunate enough to meet some of the inspiring founders of a robotics startup in the valley and decided to join this team.
Our project focused on developing indoor robots designed to automate routine tasks while providing safety and security services to people, properties, and places through cutting-edge robotics and AI systems. Our robots are capable of patrolling office spaces and warehouses, complementing existing safety measures by providing real-time situational awareness. These robots were equipped with advanced sensors like LIDAR, 3D vision cameras, ultrasonic sensors, infrared cameras, and more, making them fully autonomous.
A product like this is extremely hard to build, launch, operate, and most importantly scale! My job was three fold - ensure our product doesn’t break in the middle of demos, our fleet of robots deployed across the world is fully active 24*7, ensure each new launch that we do is successful - no major incidents or failures at least in the first 2 weeks post launch and ideally never.
During this time I realized, running a robotics startup is brutally hard. Every mistake is and every lesson comes at a significant cost. Hence if you are running a robotics startup, the best way to avoid these capital crevasses and death traps is to learn from those who’ve been through it.
We made plenty of mistakes—some avoidable, some inevitable. This post is about the lessons we learned that I hope will help future robotics founders, engineers, and investors save a ton of time, health, and capital.
If you’re new here, my first post—The Art of Building Robots in Silicon Valley—gives an overview of what it takes to build a robotic startup in Silicon Valley and the corresponding risks that come with it. Here is a link to it. This deep dive builds on that foundation, and I hope it helps you navigate the toughest parts of this journey with fewer scars.
1. The Long-Tail Problem in Robotics Is Unforgiving
No matter how much you optimize your sensors, perception and navigation system, you won’t catch everything. The long-tail scenarios i.e. edge cases in robotics are unforgivingly exponential.
Take LiDAR for example—a $10,000 sensor that’s often seen as the gold standard in robotics. Except when you realize it is not. We learned this the hard way. Each of our robots was equipped with a LIDAR that came with a hefty price tag of $10,000 at the time and yet all it took was a mere stream of photons – light particles from the sun to make it blind. This happened during a pilot run, when one of our robots navigating near a staircase was completely blinded by sunlight pouring in from a nearby window. In this state, it is probably as dangerous as a car without brakes.
There’s a solution to this, but it’s not perfect. You can add no-drive zones to your robot’s map and ensure a wide buffer area between driveable and restricted areas. It’s a workaround, but in robotics—especially in a startup—workarounds are often your best bet. This isn’t the only workaround you’ll need. If your robot keeps losing its position, you have a bigger problem–Localization.
2. Localization: Easier Said Than Done
ROS makes localization seem easy—until you realize it is not. This means in the early stages of real-world deployments, your robot will frequently cross into no-drive zones, bump into walls, people, or other obstacles.
For startups building indoor robots, localization failures are inevitable, and when they happen, robots will drift into places they shouldn’t.
We saw this happen in warehouses and office spaces with long, tunnel-like hallways. When mapped in ROS, these tunnels appear as 2D rectangular spaces on the navigation map. A robot moving continuously in a straight line on such a map will eventually lose track of its position—no matter how good the navigation system is.
Our solution? Strategically placed QR codes along hallways to help the robot recalibrate its position everytime it encountered a QR code. It worked, but it required constant calibration of sensor, precise sensor alignment, and extensive site-specific tuning. That’s the reality of robotics: solutions exist, but they come at a cost—of time, effort, and endless iterations.
And that leads us to the next lesson—the customization trap.
3. Scaling Smart: Fewer Clients, More Efficiency
In the first two phases of your journey—initial buildup and growth—resist the temptation to take on too many clients. It’s a trap.
With every new client comes a flood of edge cases. This is especially true in robotics. For every one you solve, a hundred more will surface. Soon, you're developing custom solutions for every site, every map, every hallway, office space, home, staircase, elevator, and escalator. This is the single biggest drain on resources—because custom solutions don’t scale.
Instead, go deep, not wide. Prioritize clients with cookie-cutter operational zones—consistent physical environments where your robots will operate. Work with a few clients who own multiple, similar properties. Think Costco warehouses, Walmart stores (after-hours cleanup), or Target (robotic-cart-enabled shopping and checkout). These environments don’t change much.
Scaling within such cookie-cutter spaces slashes customization costs and eliminates 90% of the operational overhead that drains most robotics startups. If you get this right, you can scale faster with far fewer headaches.
There is one more reason why this approach is startup-friendly—if you are in the B2B robotics space, a vast majority of your clients will demand integration with on-site devices and sensors. And this is much easier done if you have a few clients with a consistent setup across their sites, so the fix you develop for one can be used at others.
This means making your robot autonomous is just step one.
4. Autonomy Is Just Step One—Integration Is What Matters
For startups, providing robotics-enabled services in indoor environments like offices and warehouses, autonomy alone isn’t enough.
Your software must integrate with the client’s ecosystem. No exceptions. For example, in our case, during our early days, very few clients were willing to accept a system that doesn’t connect with any of these — their elevators, safety systems, camera networks, and card readers. Eventually we had multiple integrations in place. We realized that integration is one of the core client needs that you will need to address especially if you are a robotics-enabled service provider operating in the B2B space.
If you plan for this early, you save capital and engineering effort. If you don’t, you’ll be scrambling to retrofit these features later—at 10x the cost.
5. Running a Robotics Startup Is Like Running Multiple Companies
As our founders often put it, running a robotics startup is like running multiple companies at once—hardware, software, networking, AI, and more.
Let's start with hardware. Wherever there’s hardware—computers, sensors, batteries, chargers—failures are inevitable. And when you’re operating fleets across the country (or internationally), repairs and outages become one of your biggest operational expenses. You won’t always have the financial resources to deploy people to every site to fix every robot in time.
The only way to survive? Build redundancies into every layer of your tech stack.
If local WiFi goes down, you still need a way to track the robot’s heartbeat and ensure safe navigation.
If a sensor malfunctions, the system should auto-compensate without shutting down operations. That’s why we used LiDAR, RADAR, ultrasonics, and cameras to navigate obstacles—but even that isn’t foolproof.
Remember: Each sensor comes with its own blindspot and hence union of all doesn’t guarantee safe navigation at all. That’s why a human-in-the-loop is essential in robotics—a concept we covered in my first blog post on this topic.
One example I’d like to elaborate on is connectivity. If a local WiFi network goes down, you still need a way to track the robot’s heartbeat and ensure safe navigation. This means developing software and hardware to connect your robot to telecom networks so they can serve as a backup source of connectivity when WiFi fails.
This is easier said than done and often turns into a massive project on its own—especially for robotics companies that intend to grow their operations across different geographies, countries, and continents.
6. Global Expansion in Robotics: The Early-Stage Trap
At our startup, we expanded our robotics services across the US, UK, Australia and a few other countries. This might sound exciting in theory but it is indeed an operational maze that could easily become a nightmare.
You’re dealing with delays in shipments, variations in telecom network standards, country-specific regulations, and an endless list of logistical nightmares. What seems like an exciting milestone often turns into a slow, costly distraction from core execution.
Before scaling across borders, ask yourself: Have you truly nailed product-market fit in your home country? Do you have a repeatable, scalable model? If not, expanding too early won’t accelerate growth—it will amplify risks and inefficiencies.
While there are many of these risks that we can explore here, in the interest of time we will focus on a core one that arises with the global expansion: robot connectivity.
Getting robots to connect to telecom networks means working closely with telecom vendors—procuring hardware modules, SIM cards, and understanding how local operators had configured their networks. Integrating these details into the robot’s operating system remotely—either before shipping the robot abroad or on-arrival —can be extremely challenging.
I led this effort for 2.5 years and quickly realized that connecting robots to local telecom networks is just the beginning. The real challenge is ensuring that every layer of networking software—encryption, time-outs, feed prioritization, network selection, and more—remains synchronized and functions reliably across different telecom networks and countries.
Similarly, hardware modules (robot modems), firmware, and telecom operators vary significantly across countries. This means you will now need to meticulously track network hardware and software configurations for each robot in your fleet for each geographic region.
And it doesn’t stop there. Even within the same country, network performance can be highly inconsistent. In the U.S., for instance, T-Mobile may have stronger coverage in some cities, while Verizon or AT&T perform better in others. Expanding globally means adapting to these operational variations. You will need to plan ahead, or connectivity issues will quickly become your bottleneck.
Speaking of bottlenecks, technical bottlenecks are generally easier to address—if you have the right team structure in place. But building that structure is easier said than done.
7. The Hardest Part? Building the Right Team
Running a robotics startup isn’t just about having the right people—it’s about having the right team structure. Each team member should have their strengths, but they also need to be capable of handling tasks outside their core expertise.
For example, if you have a robotics engineer specializing in ROS—navigation, perception, localization—it wouldn’t hurt to give them a basic 101 on network debugging. Similarly, if you have a network engineer handling all things connectivity, they should learn enough ROS to troubleshoot when needed.
In my role, while I wasn’t expected to code much, I built enough hands-on skills where it mattered. I could debug ROS nodes, debug navigation issues, troubleshoot network connections, write custom networking scripts, deploy latest code to our robots, and debug hardware and software issues through the terminal.
Not because I was expected to—but because time is everything in robotics, and relying solely on experts in a crisis will not save the day! Certainly not if you are one in charge of leading demos and deployments for clients.
Working closely with our clients, managing product demos and deployments, I knew from day one that I had to understand all major components well enough to debug issues myself—at least as much as possible.
That’s because, if you are running a robotics startup, you understand that time is a scarce resource. Every demo is a hedge against the failure of one of thousands of components and software services that make your robot valuable to a client. Failures are inevitable, but learning from them early, feeding those insights to the right teams, and fixing underlying software issues is a far better use of time than escalating every single problem for an immediate fix.
In our case, this approach kept engineering teams focused on long-term improvements instead of constantly putting out fires.
Being mindful of everyone’s time is one of the most valuable lessons a team can learn. This approach keeps teams focused, cross-functionally trained, and ensures that when things go wrong, your startup isn’t paralyzed because a specific expert isn’t available.
Cross-functional teams also help mitigate talent drain—one of the biggest challenges in robotics. The field is still evolving, and companies go through cycles of rapid growth and sudden downturns. This means, building a team that is flexible, resilient, and capable across disciplines is the key to long-term survival.
Robotics startups are brutal—for both founders and team members. But if you learn fast, adapt quickly, and build a resilient team, you give yourself a real shot at survival.
Until next time - Hello Robot!
Cheers,
Prathamesh
Disclaimer: This blog is for educational purposes only and does not constitute financial, business, or legal advice. The experiences shared are based on past events. All opinions expressed are those of the author and do not represent the views of any mentioned companies. Readers are solely responsible for conducting their own due diligence and should seek professional legal or financial advice tailored to their specific circumstances. The author and publisher make no representations or warranties regarding the accuracy of the content and expressly disclaim any liability for decisions made or actions taken based on this blog.
Comments