Robotics has a marketing problem in reverse. The videos oversell the hardware and undersell everything around it. An arm repeating a taught motion is a solved problem you can buy off a shelf. An arm doing useful work inside a real company, next to real people, fed by data from systems nobody has opened since 2016, is a software project wearing a hardware costume.
We build the software half. What follows is where we watch these projects stall.
Week one always works
Every robotics project has a great first week. The vendor demo runs, the arm moves, somebody films it on a phone, and the clip ends up in a board deck.
Then the robot has to meet the world. Parts arrive rotated a few degrees off, because the upstream fixture has play in it that nobody measured. The lighting changes when the afternoon sun reaches the west windows, and a vision model that was confident all morning starts hedging. A sensor drifts out of calibration, and it drifts on a schedule that stays invisible until somebody finally plots the reject rate against the day of the week.
None of that is mechanical engineering. It’s error handling, calibration routines and logging, which is to say it’s ordinary software written by people willing to be bored.
Teams that budget the other way around, most of the money on the cell and a slice for something called integration, find out in the third month.
The integration layer is the project
A robot that can’t talk to your existing systems is an expensive sculpture.
The cell has to know what to produce, report what it produced, flag what went wrong, and stop safely when something upstream changes its mind. That means speaking to an ERP, a PLC, a camera vendor’s SDK and a database, none of which were designed to speak to each other, several of which will hand you an integer where the documentation promised a string.
That layer is invisible in every brochure. It’s also most of the timeline and most of the value. The gap between a robot that works and a robot that works inside your operation is exactly this code, and it’s the part nobody wants to pay for, because it doesn’t move.
Design the failures, not the demo
The happy path is the easy path. It’s also the only one most robotics software is really designed for.
Good cell software treats a dropped part, a low-confidence read and a dead link to the controller as designed-for states with defined recoveries, rather than as exceptions that halt the line and page somebody at two in the morning. That work is unglamorous and it is the single best predictor we know of whether a cell is still running a year after handover.
Our own test for whether a robotics project is in trouble is one question: what happens when the gripper misses? If the answer is a paragraph about the recovery routine, the project is fine. If the answer is “it shouldn’t”, the project is not fine, and usually everyone involved already suspects it.
Buy the arm, build the brain
Our advice to companies starting out hasn’t changed in years. Buy proven hardware from a vendor who will still exist in a decade, and spend the custom budget on the software wrapped around it. Custom mechanics are almost never the bottleneck. Custom logic, integration and monitoring almost always are.
We didn’t arrive at that from theory. The team behind WMinus reached the RoboCup world finals in the rescue-robot league, which is a very effective way to learn that the robot loses on the software, in front of an audience, on a schedule.
If you have hardware that works in the demo and stalls in production, that’s a software problem and it’s fixable. Tell us where it is stuck, or read more about our robotics work.