Why Robot Demos Work and Robot Products Don't

Demos work because you choose the conditions; products fail because the customer does, and no stack — ROS 2, HORUS, or your own — fixes that. A demo has to succeed once, on a floor you swept, with the person who built it standing nearby; a product has to succeed unattended, on surfaces and schedules nobody vetted. The verdict flips only when the customer's world is as narrow as your stage. The rest of this post is for teams who have a working demo, a pilot on the calendar, and a growing suspicion that the two are not related.

The video did well. Somebody senior at a company you wanted to talk to replied within a day, and now there is a pilot on the calendar.

Then the week after. Your best engineer mentions, quietly, that the run in the clip was the fourth attempt that morning. Somebody asks what happens if the customer's floor has that rubber matting near the loading door, and nobody answers. The machine has to be started in a particular order, and the order is written down nowhere, because the person who knows it has always been in the room.

Somebody else points out that the clip is a minute long and the customer wants a shift. And there is the thing nobody wants to say out loud: it worked forty times in a row on Thursday, then failed twice on Monday, and no one can say what was different about Monday.

Why does a robot demo work when the product does not?

A demo is a system tuned for one set of conditions, and a product is a system that survives conditions nobody tuned for. That is the whole difference, and it is not a difference of quality or of effort.

Everything that makes a demo succeed is legitimate and invisible. The floor was swept. The lighting was chosen. The network had nothing else on it. The objects were placed where they were placed last time. A person who knows every failure mode stood a metre away with a hand near the stop button, ready to intervene before anything embarrassing happened.

A product gets none of that. The floor has a puddle by the door in winter. Somebody parks a pallet in the aisle. The network has a hundred devices on it and a scanner that shouts. The machine runs for a shift, then another, and the person nearby is a supervisor who was told the robot handles itself.

So the demo was never a small product. The demo proved one point in a space works. The product needs most of the space.

What is the demo-to-product gap in plain terms?

The gap is everything a demo is allowed to assume and a product is not. There are four, and each costs real months to remove.

The first is that somebody is watching. In a demo, the arm stops before it hits the table because a human had a finger on the button. In a product, the machine has to notice the table itself.

The second is that the environment was prepared. Demos happen in a place that was made ready. Products happen in places that change while the robot is in them.

The third is that the run is short. Almost nothing that kills robot products shows up in the first minute. Memory creeps, temperatures rise, a queue fills, a sensor drifts, and a stack that has been up since Tuesday behaves unlike one that was started five minutes ago.

The fourth is that failure is a retake. In a demo, a bad run gets deleted. In a product, a bad run is a support call, a scratched wall, or a customer who stops answering.

What does the gap look like on the day it shows up?

It shows up as a machine that works all morning and does something inexplicable after lunch, with nothing in the logs that accounts for either. That is the signature, and most teams meet it the first week the robot lives outside the lab.

The symptoms are boringly consistent. The arm reaches for where the cup was rather than where it is, because the camera data arrived after the decision was made. The robot hesitates mid-motion, briefly, and everyone pretends not to have seen it. Someone connects a laptop to the site network and the machine starts behaving differently, which sounds absurd and is extremely common.

The stack needs restarting between runs and nobody wrote that down. One engineer can bring the system up and the others cannot. Two identical runs produce two different outcomes, which is the symptom described in why a robot behaves differently every run and the clearest early sign among the things that suggest a prototype will not survive production.

What are your real options for turning a demo into a product?

There are six, and most teams run two at the same time. The first is to harden what you already have: keep the stack, add recovery and logging, write the start-up procedure down, narrow the claim. The second is to rebuild on ROS 2, which trades months of your own integration work for the largest body of existing drivers, navigation and manipulation packages, and engineers who already know the tooling.

The third is to keep the structure and move the timing-sensitive path onto a real-time middleware. HORUS is one such option: an open-source, Apache-2.0 middleware for Rust, Python and C++ in which all three languages share the same shared-memory ring buffers, so messages between processes on one machine are not serialised and the camera data reaches the controller before the next decision needs it. The project is validated in simulation and replaces neither the navigation stack nor the driver ecosystem ROS 2 gives you.

The fourth is a vendor platform or an integrator. The fifth is to narrow the product until the demo is the product. The sixth is to keep a human in the loop and sell the outcome rather than the autonomy.

How do the routes from demo to product compare?

The useful comparison is what each route assumes about your team, not what it promises about the robot.

Four of those seven rows are the same team choosing a different scope, which is where the decision usually sits.

Which route fits a two-person team with a video and no customers yet?

Narrow the product until the demo is the product, then harden that and nothing else. Two people cannot maintain a general-purpose robot, and every capability kept from the video is one somebody supports at two in the morning eighteen months from now.

The move is to find the customer who pays for exactly the trick in the clip. Not the adjacent trick, not the trick plus a second one. If the video showed a machine sorting one kind of object into one kind of container, sell that, and let the next capability wait until somebody pays for the first.

This is unsatisfying advice for a team that just had its best week, and it is the difference between shipping and drifting. The alternative, which nearly every small team tries, is to keep the demo general and harden all of it at once. That fails because there is not enough of you.

A smaller stack helps here too, since the maintenance lands on the same two people. The middleware trade-offs for solo builders and two-person teams are about how much you can carry, not what you can build.

What changes if the robot has to carry its own computer?

Everything the laptop under the table was quietly doing becomes your problem, and most of it was never written down. That is the most underestimated transition in the whole demo-to-product path.

The desk machine had a graphics card, mains power, a fan that could spin up, and a filesystem nobody worried about. The on-board computer has a fraction of that, shares power with the motors, sits inside a warm enclosure, and gets slower as the enclosure warms. Work that fit comfortably on the bench stops fitting, and the first symptom is usually the machine hesitating rather than anything crashing.

The second change is that the network becomes internal. A demo often has processes spread across a laptop and the robot, chatting over a cable with nothing else on it. On the machine, those processes share one small computer, and how they hand data to each other stops being free.

That is the moment the software choices for small on-board computers stop being an abstract preference and start setting what the robot can do.

What can you actually finish before a pilot three months away?

One narrow behaviour, made repeatable, plus the operational scaffolding around it. Not a rewrite, not a second capability, and not a migration to a different stack unless the current one is the diagnosed cause of failure.

Spend the weeks on four things. A start-up procedure a person who did not build the robot can follow from a written page. A stop that works in every state the machine can be in, including the states you did not plan for. Logging that survives a crash and can answer why the robot did that on Tuesday. And a way to reproduce your most common failure on demand, because a fault you cannot summon is a fault you cannot fix.

None of that appears in a demo, and all of it is what the pilot tests. Teams that spend the quarter on a rewrite instead arrive with a cleaner codebase and the same demo, now less understood, because the knowledge lived in the old code. That pattern is most of why robotics projects stall after the prototype.

Which route works if nobody on the team has shipped hardware before?

ROS 2, plus somebody who has taken a machine to a customer before, because what is missing is judgement rather than code. A team of strong software engineers with no hardware history will write good software and get surprised by the physical world in exactly the ways everyone gets surprised, only later and more expensively.

ROS 2 is the right default here for an unglamorous reason: the pool of people who have already done this is largest there. Hire a contractor for six weeks and they are useful in the first week rather than the third. The packages are not the main value. The shared vocabulary is.

Bring that person in before choosing the stack, not after. The costliest decisions in a robot project get made in the first fortnight by people who do not yet know which decisions are costly. A short engagement with someone who has run a fleet changes how you scope the product, which matters more than any framework question.

If nobody is available, the honest fallback is to keep the human in the loop until somebody is.

What do you give up by rebuilding the demo properly?

You give up the pace that made the demo possible, and almost nobody is warned about that in advance. It is the single most demoralising part of the transition, and knowing it is coming helps.

In demo mode, a change takes an afternoon and the result is visible immediately. In product mode, the same change takes a week, because it needs a failure path, a test, a note in the start-up procedure, and a way to tell whether it worked on a machine you cannot see. The work stops being about capability and becomes about what happens when things go wrong, which is less fun and is the actual job.

You also give up capability, deliberately. Narrowing means the impressive part of the video may be cut, and that hurts more than it should because the video is what got you the meeting.

And you give up freedom. The demo could be edited by anyone at any time. The product cannot, because a change nobody reviewed is how a machine does something surprising in a building you are not standing in.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever your main risk is integration rather than timing, which covers most teams making this transition. If your product needs navigation, mapping, manipulation planning, or a driver for a sensor that somebody has already written a driver for, ROS 2 hands you those and a newer stack does not.

ROS 2 also wins when you are hiring, when a customer or partner requires it, when your hardware vendor ships ROS 2 support and nothing else, when your robots coordinate across several machines, and when the people maintaining this after you are researchers or contractors who already speak it.

HORUS is not the answer in any of those cases. It is a middleware, not a robotics platform: no navigation stack, no simulator, no driver ecosystem, and a much smaller body of public example code to lean on at midnight. Choose it only where on-machine timing is the diagnosed problem, and read the direct comparison before assuming timing is your problem, since usually it is not.

Is the demo-to-product gap just a testing problem?

No, and here is why: testing tells you the demo breaks, while the reason it breaks is usually a design decision made in the first week. You can add tests to a system that has no recovery path and all you get is a well-documented list of the ways it stops.

The demo's structure encodes an assumption that a person is present. Nothing in it decides what to do when the object is not where it was expected, because in the demo the answer was that someone reset the scene. Testing that system produces failures you already knew about and never says what the machine should do instead, which is a design question and a product question.

There is a second limit. The tests you write are the failures you imagined, and the ones that hurt at a customer site are the ones nobody imagined, like a cleaner moving a bin every Thursday evening.

So the sequence is: change what the system does when surprised, then test that the new behaviour holds. Testing first measures the old design more precisely.

Does better hardware close the gap?

Partly, but not the way you think: better hardware removes one class of failure and makes the class underneath visible. That is genuinely progress, and it is not the finish line teams expect it to be.

Better sensors mean less noise to fight. A stiffer arm repeats a motion more closely. A bigger on-board computer stops the hesitation that came from data arriving late. Each buys margin, and margin is worth paying for early, when you do not yet know which failures are yours and which are the machine's.

What is left afterwards is harder. The remaining failures are about a world that changes and about what your software does when surprised, and no component upgrade decides that. A team that keeps buying hardware to fix behaviour ends up with an expensive machine that fails in the same situations as the cheap one, just more smoothly.

There is also a cost nobody budgets: every hardware change resets some of your tuning, and the schedule assumed the tuning was done.

How do you decide what to rebuild and what to keep?

Sort the demo into three piles: what has to be correct every single time, what only has to be good enough, and what existed for the video. Rebuild the first pile, leave the second until it causes a problem, and delete the third before it becomes someone's responsibility.

The first pile is small and obvious once you look: anything that commands motion, anything that decides to stop, anything a safety argument rests on. That code gets rewritten deliberately and reviewed by someone who has watched the machine run. The second pile is most of the repository, and rewriting it early is how quarters disappear.

Then apply two tests. Can someone who did not build the robot start it from a written page and get a normal run? Can you answer, from the logs alone, why the machine did what it did last Tuesday? A no to either is worth more of your remaining time than any framework migration.

• If you have a video and no customer -> narrow the product to the demo, because two people cannot support a general machine.
• If your integration list is longer than your behaviour list -> rebuild on ROS 2, because that work is already done and shared.
• If the machine hesitates once it carries its own computer -> fix the on-machine data path, because no amount of tuning cures late data.
• If nobody has shipped hardware before -> hire or contract that experience before the stack decision, because the costly calls come first.
• If the pilot is close -> harden one behaviour and write down how to run it, because that is what a pilot actually measures.

The HORUS Fit Framework reduces the stack half of this to five non-numeric axes: ecosystem size, setup effort, team size fit, deployment target, and licence. Crossing from demo to product, deployment target and team size fit usually decide it, and ecosystem size decides how lonely the next six months feel.

If the on-machine timing turns out to be your real problem rather than your suspected one, put HORUS on the reading list rather than into this sprint: star it so it is in your list when you start building.