Should a Startup Build on ROS 2 or Something Else?

A startup should build on ROS 2 rather than a custom stack or a niche middleware, because the drivers and tools already exist. Demos are won with capability, not timing, and ROS 2 supplies capability you would otherwise spend a funded year rebuilding. That flips when the product is the motion itself and the loop keeps missing deadlines, the case a shared-memory middleware such as HORUS exists for. The rest of this post is for founders and first engineers choosing a stack in week one and worried about being stuck with it three years later.

The argument has already happened twice. One of you built on ROS in a lab and knows exactly how the first month goes. The other has shipped firmware, thinks the whole thing is a research toy, and expects to spend a year deleting it. Nobody has written a line of production code yet, and the calendar has a date on it: a demo, an investor meeting, a pilot customer who wants to watch the machine move.

Meanwhile the questions arriving from outside are not technical ones. A prospective hire asks what the stack is, and you can hear them working out whether the job is a career step. An investor asks why you are not using the standard thing, in a tone that makes the expected answer obvious. Someone forwards a post claiming the standard thing cannot do real time, and someone else forwards the reply. You are making a decision that outlives every other decision this quarter, with less information than you will ever have again. The fear is not picking wrong. It is picking wrong and finding out much later.

What should a startup actually build its first robot on?

Build on ROS 2 unless the thing you are selling is the motion itself. A startup's scarce resource is not compute or elegance, it is calendar. Every part of the stack you do not have to write is time handed back to the machine a customer is actually paying for.

Most robotics startups are not selling a control loop. They are selling that a machine can do a real job in a real building, which turns out to be a perception problem, an integration problem and a does-it-still-work-on-Thursday problem. None of those are solved by the message transport, and all are easier in an ecosystem where somebody already wrote the driver for the sensor you just ordered.

The exception is narrow and real. If the pitch is that your machine moves in a way the incumbents cannot, then motion is the product, timing is a feature, and the stack decision moves from plumbing to specification. That is a minority of startups, and being in it is obvious from the physics.

What does a robotics stack actually give a small team?

A stack gives you the parts of a robot that are not your idea. Named streams that any program can publish to or read from. A way to start twenty programs together and stop them together. A way to record everything that happened on the machine and replay it at a desk afterwards. Drivers for cameras, lidars, arms and motor controllers, written by people who read the datasheet so you do not have to.

The recording and replay part is the one small teams underrate and later depend on. A failure that happens in a customer's warehouse, once, at the end of a shift, is either a recorded run you can study on a laptop or it is a story somebody tells you second-hand. That difference decides whether a bug takes a day or a quarter.

The stack also decides whether messages between your programs are copied and converted or handed straight over, which is invisible while the robot is unhurried and becomes the whole conversation once it is not.

What are the realistic stack choices for a startup?

There are five: ROS 2, ROS 2 with a faster core underneath the hot loop, a shared-memory middleware on its own, a commercial real-time framework, or one program you write yourself. ROS 2 is the default and has earned it, bringing navigation, mapping, visualisation, recording, simulator integration and a large body of vendor-written drivers, with messages between processes converted into a neutral format on the way out and rebuilt on the way in. HORUS is the open-source example of the shared-memory answer: an Apache-2.0 real-time 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 at all. The project is validated in simulation and is not a full ROS replacement for every project.

The hybrid deserves more attention than it gets. Keep the ecosystem for perception, drivers and tooling, put the deadline-bound loop on something built for it, and bridge between them. Most teams who think they are choosing are actually choosing where the boundary goes.

How do the stack choices compare for a small team?

Read the last column first, cross out every row that describes your company, and see what is left.

Notice that only one row is about timing. The rest is about people, money and time.

What do startups build first, and when does that stop working?

Almost every robotics startup begins with one script on a laptop driving the hardware directly, and that is the correct beginning. It proves the mechanism, it fits in one head, and it can be rewritten on a Sunday.

It stops working at one of three moments. The second engineer arrives, and now two people are editing one file and one crash takes down everything. The second computer arrives, because the camera you chose needs more than the board can give. Or the robot leaves the building, and suddenly you need to know what happened at a customer site without a person standing next to it.

That third moment is where projects stall, and the pattern is common enough to have a shape of its own. The script that made the demo cannot be instrumented, cannot be replayed and cannot be handed to a new hire. Teams then adopt a stack under deadline pressure, which is the worst possible time to learn one.

Are you two founders in a garage or a funded engineering team?

Two founders should take the option with the most answers already written down, which today means ROS 2. When there is nobody to ask internally, the internet is your senior engineer, and the size of the community is the size of your support team. A stack with fewer users costs you evenings, and evenings are the only budget a pre-seed company actually has.

A funded team changes the arithmetic. With several engineers you can afford one person who owns the plumbing, reads source when documentation runs out, and treats an unusual choice as an asset.

There is a middle case worth naming, because it is the most common one. A team of two or three engineers with a real timing problem should not choose between ecosystems. Keep the ecosystem for everything above the loop, and build only the loop on something suited to it. Owning a small amount of unusual technology is survivable. Owning a whole unusual stack, with two engineers, generally is not.

What hardware is your product going to ship on?

The board on the robot decides more than the software argument does. One modest computer running perception and control together is the case where copying and converting messages is felt, because there is no spare capacity to hide it. Several computers on one machine, or several machines across a site, move the constraint into the network, and no local trick reaches across a cable.

A microcontroller beside the motor ends the discussion for that loop entirely. If a behaviour must survive the main computer being busy, the honest answer is often firmware rather than middleware.

There is a commercial angle here too. Sometimes the cheapest fix is a bigger computer, and a startup should price that against engineering months before optimising anything. Sometimes it is not, because the board is fixed by weight, power or the cost of the unit you have to sell at a margin. If the bill of materials is what makes the business work, the software has to fit the board, and that should be written down before anybody argues about transports.

How long until you have to show a robot that works?

If a robot has to move in front of people within weeks, use the ecosystem and revisit everything else afterwards. Timing behaviour is worth nothing when there is nothing moving yet, and no investor has ever been talked out of a cheque by a message transport. The first version exists to find out whether the mechanism, the sensors and the business idea survive contact with reality.

The second machine is the right place for the harder conversation. By then you know which loop is tight, which messages are large, and which behaviour a customer notices. A targeted change is cheap at that point, because you are moving one loop instead of rebuilding a stack you have not written.

There is one exception to the wait-and-see rule. If a safety behaviour has to happen within a fixed window, that is a specification, not an optimisation, and it belongs in the first design. Retrofitting a stopping guarantee onto a stack chosen for convenience is one of the more expensive mistakes available to a robotics company.

What does your team already know how to write?

Build on what your team can already debug at midnight before a customer visit. A first engineer who writes Python well and has never touched C++ will move faster on a stack that lets them stay in Python; a team from an embedded background will be happier closer to the metal. The decision is not which language is better. It is which one your people are fluent in when something is broken and the room is tense.

This matters more for startups, because your team will change. Every hire has to learn the stack, and the choice you make now sets the length of that ramp for years. An unusual stack means either training every hire or hiring from a smaller pool.

The useful question is what a stack asks you to know that you do not know today. If the honest answer includes learning a language, a build system and a middleware at the same time, that is three unknowns during the period when you can least afford surprises.

What do you give up by building on something other than ROS 2?

You give up the hiring pool first, and that is the cost founders underestimate most. ROS 2 is what robotics graduates already have on their CVs, and a job advert naming something else means longer searches and a longer ramp for every engineer who joins.

Second, you give up packages: navigation, mapping, visualisation, simulator integration and vendor drivers, each already debugged by someone in conditions you have not met. Rebuilding one of those is a project. Rebuilding several is a different company from the one you pitched.

Third, you give up legibility. Investors, acquirers and pilot customers all read a stack choice as a signal, and explaining an unusual one costs you minutes in every diligence conversation. That is survivable when the reason is good and expensive when it is a preference.

The way out is to give up less. A hybrid arrangement keeps the ecosystem where the ecosystem is strong and confines the unusual choice to the loop that needs it, which is also the part a new hire does not touch in week one.

When is ROS 2 the better choice?

ROS 2 is the better choice for most startups, and HORUS is not the answer when what you need is packages and people rather than message timing. If your robot must map a building and navigate it, use the navigation stack that exists. If your sensor vendor ships a driver, use it rather than reading a datasheet for a fortnight. If your pilot customer wants a demo this quarter, take every shortcut the ecosystem offers, because a shipped demo beats an elegant architecture.

ROS 2 also wins on the things founders forget to count. Contractors you can hire by the week already know it. Simulators integrate with it. University collaborators can read your code.

And the most common case: a team whose robot is disappointing for reasons that have nothing to do with software plumbing. A miscalibrated camera, a gripper that was never going to hold that part, a controller nobody has tuned. Migrating a message bus will not fix any of those, and the migration will consume the quarter that could have.

Will the middleware choice decide whether the startup survives?

No, and here is why: startups die of no customer, not of message transport. The graveyard is full of excellent robots that solved a problem nobody would pay to have solved, or cost more to build than anyone would pay. Nobody in that graveyard is there because messages were copied between processes.

What the choice does decide is how much of your calendar goes to work customers never see. A stack that fits your problem gives you weeks back over a year; a stack that fights you takes them away, quietly, in workarounds nobody planned and nobody documents. Over a couple of years that difference is real, but it is a compounding cost, not a fatal one.

So make the decision quickly, make it defensible, and move on. The correct amount of time for a seed-stage company to spend comparing middleware is days, not weeks. If the debate has run longer than that, it has stopped being a technical question and become a proxy for something else the founders disagree about.

Is the stack choice locked in once you take money?

Partly, but not the way you think: the code is portable and the organisation is not. Node bodies move easily, because a node body is mostly your algorithm and your algorithm does not care how the bytes arrived. Read a sensor, run a filter, publish a result. That part is a week of work at prototype scale.

What does not move is everything around it. Launch configuration and parameters. Recorded runs and the tools that read them. Your test rig and continuous integration. Your simulator setup. And the largest one, the assumptions your team holds without stating them, which is why migrations feel harder than they look on paper.

The lock-in is therefore social and it grows with headcount. Changing stack with three engineers is a fortnight of grumbling; changing with fifteen is a quarter with a project plan. That argues for deciding deliberately at the start, and against treating the decision as permanent. Startups that keep a clean boundary between their robot code and their transport pay a small tax early and keep the option open.

How should a startup make this call in a week?

Write one sentence describing what you sell, and let that sentence pick the stack. If it reads "our robot finds its own way around a building and picks things up", the answer is the ecosystem, because every part of that sentence already exists as a package. If it reads "our arm moves in a way nobody else's does", the answer involves timing, and what happens between processes is part of your product rather than part of your plumbing.

Then spend a few days, not a month, on the thing that will hurt. Build the ugliest part of your robot on the hardware you intend to ship, in the language your team writes, and watch the machine rather than a chart. Ask whether a new hire could build it from a clean checkout, whether you can replay a failing run, and what the robot does when a process is killed.

Then write the decision down, with the reason, where your future team can find it.

• If you are pre-seed with a demo in six weeks -> ROS 2, because drivers you do not have to write are the cheapest engineering you will ever get.
• If customers judge your machine by how it moves -> the ecosystem around a shared-memory core, because the loop is what you are selling.
• If you sell into a regulated setting where an auditor reads your paperwork -> a commercial framework, because the certification path is part of the product.
• If your machines and data span several sites -> ROS 2 with a network-first transport, because the link is the constraint.
• If you are two engineers with one machine and one language -> one program and no middleware, because the architecture you can hold in your head ships first.
• If you are already productive and the complaints are about your own maths -> stay where you are, because a migration will not tune a controller.

The HORUS Fit Framework reduces the whole comparison to five axes: ecosystem size, setup effort, team size fit, deployment target, and licence. Score each option on all five, and pick the one that is not red on the axis your company cannot afford to lose.

If timing turns out to be the axis you keep returning to, put HORUS on your reading list rather than on your roadmap: star it so it is in your list when you start building.