Should Your Robotics Startup Build on ROS 2 or Roll Your Own?

Build on ROS 2 rather than rolling your own stack, unless the way your robot moves is the product you are selling. Writing your own transport, launch, recording and drivers costs a funded year no customer pays for, and the ecosystem hands all four over written. That flips only when the deadline-bound loop is the product itself, which is the narrow case a shared-memory middleware such as HORUS serves. The rest of this post is for founders and first engineers choosing between adopting a stack and owning one, with a demo date already in the calendar.

It usually starts with a sentence someone says with total confidence: it is only publish and subscribe, we can write that in a fortnight. And the first weekend proves the point. Two programs pass messages, the wheels turn, everybody goes home pleased.

Then the questions arrive that the fortnight did not cover. How do we start eleven programs in the right order and stop them together when somebody hits the switch. How do we see what the machine believed at the moment it drove into the pallet. How do we replay yesterday's failure at a desk instead of in a warehouse. Who writes the driver for the lidar arriving on Thursday. What is supposed to happen when one program dies and the other ten carry on as though nothing did.

Meanwhile the other founder has lost a day to an install that was meant to take an hour, has read a network configuration page twice without understanding it, and is now quietly certain the standard thing is a research artefact you would be mad to ship. Both of you are right about something. Neither of you has the calendar to be right slowly.

Should your startup build on ROS 2 or write its own stack?

Build on ROS 2, and treat writing your own stack as a decision you have to justify rather than a default you drift into. The scarce resource at a robotics startup is not compute and not elegance, it is calendar. Every part of the machine you do not have to write is a month handed back to the part a customer is actually paying for.

Most robotics companies are not selling message passing. They are selling that a machine does a real job in a real building on a Tuesday, which turns out to be a perception problem, an integration problem, and a does-it-still-work-after-the-cleaner-unplugged-it problem. None of those are solved by the plumbing, and every one of them is easier somewhere that already has a driver for the sensor you ordered last week.

The justification for owning the plumbing does exist and it is narrow. It applies when the motion itself is the product, when the whole robot runs on one computer, and when the list of things you would otherwise have imported is short enough to write on a napkin. That is a minority of companies, and the ones inside it can usually tell from the physics rather than from the architecture diagram.

What does rolling your own robot stack actually mean?

Rolling your own means owning the plumbing between your programs, and the plumbing is far larger than the message passing everyone pictures at the whiteboard. Message passing is the easy weekend. What comes after it is the year.

You need a way to start a dozen programs in a defined order and stop them together. A way to hand each one its settings without recompiling. A way to record everything that crossed the machine and read it back at a desk afterwards. A way to draw what the robot believed about the world at the moment it did the wrong thing. A shared idea of time, so replayed data and live data behave the same way. Then drivers, one per device, each written by somebody who read a datasheet you would rather not read. That list is what middleware actually does in a robot, and none of it is visible in a demo.

There is an honest, cheaper version of rolling your own that teams rarely name out loud: one program, no middleware at all, everything in a single process. That is a real architecture with real advantages, and it is not the same decision as writing a middleware. Confusing the two is how a fortnight estimate becomes a year.

What are the real options between ROS 2 and a stack you write yourself?

There are six real options, and only one of them is writing a middleware from scratch. 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 opposite end: an Apache-2.0 real-time robotics middleware for Rust, Python and C++ where 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 does not replace the ROS ecosystem for every robot.

Between those two sit the ones most teams actually end up on. Keep the ecosystem and put a shared-memory core under the one loop that keeps missing its deadline. Write a single program with no middleware, which is how many good robots get built without ROS at all. Buy a commercial real-time framework because an auditor will read your paperwork. Use a network-first transport because your problem is a fleet across a site, not a loop on a board.

How do the options compare for a startup with a deadline?

The useful comparison is not which option is best, but which one matches the shape of your company this quarter.

Read the last column first. Most stack arguments are two people comparing different rows without noticing, and the fastest way to end one is to agree on which row your company is in before arguing about which row is best.

Which option fits a founding team of three with one robotics hire?

Three founders with one robotics hire should build on ROS 2, because your one robotics engineer is worth far more solving your problem than rebuilding a solved one. With that ratio, every week spent on plumbing is a week the only person who can build the actual robot is not building it.

The failure mode here is specific and common. The robotics hire is usually the strongest engineer in the room, enjoys systems work, and can genuinely write a decent transport. They will produce something good. Then they become the only person who understands it, which quietly makes them unpromotable and unhireable-around, and every future engineer arrives to a codebase with no documentation, no community, and no error message anyone can search.

The version that works at this size is boring. Adopt the ecosystem, write your algorithms as ordinary programs that read inputs and publish outputs, and keep the boundary between your logic and the transport clean enough that the transport could be swapped without touching the maths. That costs almost nothing early and preserves the option you may want at fifteen people.

Does your hardware decide whether you can write your own stack?

Your hardware decides most of it, and the question that decides it is how many computers your robot has and how many devices you did not build yourself. Every device you did not build is a driver you either import or write, and writing one is a week you did not plan for.

One board, two devices you designed yourself, one language: a single program is a defensible architecture and a middleware is overhead. One board, a depth camera, a lidar, an arm and a motor controller from four vendors: the ecosystem has already written four of your next four weeks, and declining that is an expensive gesture.

Several computers on the robot, or several robots per site, changes the question again. Now the messages cross a wire, and everything about how they get lost and how they get found matters more than how fast they are copied. Startups often discover this order backwards, optimising the path between two programs on one board while the real problem is what the network does when a lift door closes.

What should you pick when the demo is eight weeks away?

With eight weeks, pick the ecosystem and stop having the argument. A demo is won by capability, not by architecture, and nobody watching a robot move has ever asked what carries the messages. The stack that wins a demo is the one with the fewest new things in it.

Eight weeks buys you roughly one hard thing. Spend it on the mechanism, the perception, or the one behaviour that makes your company different, and take everything else off the shelf, including the parts you are confident you could write better. You probably could. It does not matter this quarter.

There is a second reason, less obvious and more important. A demo you build on the standard stack can be understood by anyone you hire afterwards, shown to a customer's engineer without a tutorial, and extended by a contractor if the eight weeks turn into four. A demo on a home-grown stack is a demo plus a training obligation, and you will discover the second half of that sentence at the worst possible time.

Does your team have the skills to maintain a stack it wrote?

Most small teams can write a stack and cannot maintain one, because writing is a project and maintaining is a permanent job done mostly by people who were not there for the writing. The skill question is not whether your engineers are good. It is whether your fourth engineer, hired in eighteen months, can fix your transport at two in the morning in a customer's building without phoning a founder.

Ask three concrete things. Can a new hire clone the repository and have the robot moving on their first day, without anyone sitting beside them. When a message goes missing, is there a way to find out where, or does that turn into a two-day investigation led by whoever wrote it. If the person who built the plumbing left tomorrow, how long until the next release.

If those answers are uncomfortable for a stack that already exists, they will be worse for one you have not written yet, because the version in your head is always the maintained one.

What does rolling your own look like a year later when it goes wrong?

It goes wrong quietly, as a tax rather than a crash. The transport keeps working. What stops working is everything you did not think of as part of the transport.

A customer reports that the robot stopped in an aisle on Thursday. You have no recording, because recording was on the list after the demo. So you reproduce it in the warehouse, at their convenience, with two engineers and a hire car. A new engineer joins and takes three weeks to be useful, because there is nothing to read. A bug appears in the machine's behaviour and the first argument is whether it is a bug in the behaviour or a bug in your plumbing, which is a question the ecosystem's users never have to ask.

Then the second computer arrives. Or the second robot. Or a customer wants remote monitoring. Each one is a feature of a normal stack and a project in yours. None of it is dramatic. It shows up as a roadmap where every quarter has infrastructure work in it that nobody outside the building would recognise as product.

What do you give up by building on ROS 2?

You give up control over timing, and some of your own understanding of your machine. The path a message takes between two of your programs is written by people you will never meet, configured by defaults you did not choose, and can be studied but not held in your head the way your own code can.

You give up some days at the start. The install is longer than it should be, the network configuration surprises people, and the first week includes at least one afternoon lost to something that is not your robot. You also give up the ability to say exactly what happens when a message crosses between processes, because it is copied, converted and rebuilt on the way, which is invisible while the machine is unhurried and becomes the entire conversation once it is not.

And you give up a certain kind of pride. Most teams find this an easy trade, and the ones who do not should notice that the feeling is about them rather than about the customer.

When is ROS 2 the better choice?

ROS 2 is the better choice for most robots, most teams and almost every first product, and HORUS is not the answer whenever any of the following is true. You need navigation, mapping or manipulation and would otherwise implement them yourself. You have hardware from several vendors and want drivers rather than datasheets. You are hiring, and want candidates who already know the stack on day one. You need a simulator in the loop and want the integration to exist already.

It is also the better choice when your machines are spread across a network, when your team is still learning robotics, and when your deadlines are measured in a person's patience rather than in control cycles. And it stays the better choice when you are already productive on it and the complaints are about your own algorithms, because scaling to a commercial product is mostly about discipline rather than transport.

Choose something else when the motion is the product, the machine is one computer, and the loop misses deadlines you can see in the way the robot behaves. That is a real situation. It is not most situations.

Is ROS 2 too heavy to put on a product robot?

No, and here is why: the weight is mostly optional, and shipping teams routinely run a small subset of it. The default installation is a superset assembled for research, teaching and every kind of robot at once. Nothing obliges you to launch all of it, and production robots typically run a trimmed set of processes with the rest never started.

The things that actually bite in production are not size. They are startup order, what the machine does when one process dies, network configuration on a customer's site, and how the robot behaves in the first seconds after power-on. Every one of those is a discipline problem that a home-grown stack has as well, except that in a home-grown stack you also have to build the tools to investigate them.

Where the heaviness is real is in comprehension. A large ecosystem means large parts of your robot were designed by strangers for different robots, and a team that never reads any of it will be surprised eventually. That argues for one engineer who genuinely understands the layer underneath, not for replacing it.

Does writing your own stack make a small team move faster?

Partly, but not the way you think: writing your own is genuinely faster for about a quarter, and then the curve inverts. In the early weeks there is nothing to learn except your own code, no configuration you did not choose, and no unfamiliar error messages, which feels like speed because it is speed.

The inversion has three triggers and you will hit at least two. The second computer, when messages have to cross a wire and everything about that is now yours. The third engineer, when onboarding becomes a cost you pay repeatedly and there is no documentation but the code. And the first customer failure you cannot reproduce, when the tooling you postponed turns into a week in someone else's building.

What you actually bought in that first quarter was speed in the part of the robot no customer pays for. The teams that look fastest at eighteen months are usually the ones who were slightly slower in month one because they were learning somebody else's stack instead of writing their own.

How do you make this call in a week and move on?

Write one sentence describing what you sell, and let that sentence choose 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 phrase in that sentence already exists as a package somebody maintains. If it reads "our arm moves in a way nobody else's can", timing is a specification rather than plumbing, and the stack decision is part of the product.

Then spend a few days, not a month, on the part that will hurt. Build the ugliest piece of your robot on the hardware you actually intend to ship, in the language your team writes, and watch the machine rather than a chart. Ask whether a new hire could get it running from a clean checkout, whether you can replay a failing run at a desk, and what happens when you kill a process at random. Those three answers predict your next two years better than any comparison table, including the one above. If you are leaning on tooling to write the first version, read what coding assistants can and cannot do on robot software before you decide how much of it to trust.

Then write the decision down, with the reason and the date, where the team you have not hired yet will find it.

• If you are pre-seed with a demo in eight weeks -> ROS 2, because drivers you did not write are the cheapest engineering you will ever get.
• If you have one robotics engineer and two other founders -> ROS 2, because that engineer's time is the company's real budget.
• If your robot is one board, one language and two devices you designed -> one program and no middleware, because the architecture you can hold in your head ships first.
• If customers judge your machine by how it moves -> the ecosystem with a shared-memory core under the loop, because the loop is what you are selling.
• If you sell into a setting where an auditor reads your paperwork -> a commercial framework, because the certification path is part of the product.
• If your product is the stack itself -> write it, because that is the one case where the plumbing is revenue.

The HORUS Fit Framework reduces the whole comparison to five axes: ecosystem size, setup effort, team size fit, deployment target, and licence. Score every option on all five, and pick the one that is not red on the axis your company cannot afford to lose. A stack you wrote yourself scores well on deployment target and badly on ecosystem size, and that trade is the entire decision.

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