How Small Robotics Teams Ship Faster Than Big Ones

Small robotics teams ship faster because coordination costs them almost nothing, not because they are cleverer, and that advantage ends at a predictable size. A team of three keeps one shared picture of the robot, so a decision made on Tuesday is in the code on Tuesday. That flips once the work needs certification, a supply chain or a fleet in the field. This post is for a small team choosing what to build on, weighing ROS 2 against a lighter base such as HORUS, and deciding what to fix first.

You are four people and a robot in a room. Last month you rebuilt the entire perception path in a week, because the person who wrote it was sitting next to the person who needed it changed. You know a larger company with a department for that part, and they are still in review.

It does not feel like an advantage from the inside. From the inside it feels like nothing is written down, the robot's real behaviour lives in one person's head, and every demo is preceded by an evening of fixes nobody can explain afterwards. You keep reading that you should adopt process, standard tooling and a proper architecture, and each time you try, a week disappears into configuration while the robot moves no better.

So two fears pull in opposite directions. One says you are quick because you are skipping the things that matter, and the bill arrives later with interest. The other says that the day you start behaving like a large company, you lose the only real advantage you have.

Nobody tells you which of the two is true for the robot you are actually building.

Why do small robotics teams ship faster than big ones?

Small teams ship faster because a decision costs one conversation rather than a meeting, and because a robot resists being divided into parts with separate owners. When the arm stutters at the end of a reach, the cause might be the motor driver, a message arriving late, a loose mount, or a filter someone tuned last week. A team of four follows that chain in an afternoon because the whole chain is in the room. A team of forty routes the same question through three owners, two calendars and a shared document, and the robot is still stuttering on Friday.

The second reason is that fewer people means fewer agreements, and agreements get renegotiated whenever reality argues back. Robot projects change their minds constantly, because the floor is more slippery than expected and the gripper drops the third object out of ten. Every interface frozen before that discovery becomes a thing to unfreeze.

None of this is about effort: large teams contain excellent engineers spending their days on coordination a small team never has to buy. The advantage is structural, which is also why it does not last forever.

What does shipping actually mean for a robot team?

Shipping means a robot doing its job in someone else's building without you standing next to it, and everything before that is rehearsal. This matters because the small-team advantage is enormous in rehearsal and much smaller in the real thing. A demo ships attention. A deployment ships responsibility: updates that must reach a machine you cannot see, spare parts, a person on site who did not build it, and a failure mode that has to be safe rather than interesting.

Between those two lies a stage most teams underestimate, where the robot works for a week without you. That is where undocumented knowledge turns into downtime, and where the habits that made you quick start charging rent.

The honest framing is that small teams win the first two stages decisively and have to earn the third. Winning it does not mean becoming a large company. It means picking up a short list of practices that exist to preserve truth rather than to coordinate people. Why robot demos work and robot products do not is the longer version of that gap.

What slows a big robotics team down that a small one never notices?

The cost of agreeing slows them down, and it appears on no invoice. When three groups own perception, control and hardware, the interfaces between them get fixed early, because that is what lets everyone work in parallel. Robotics punishes this, since the right shape of an interface is usually discovered by building the thing twice. A small team simply changes both sides. A large team schedules that change.

Then come the smaller taxes. The simulator is maintained by another group, so it lags the robot. The test rig is booked. The environment that produces a working build lives on one machine and nobody remembers how it was made. Hardware runs on a manufacturing cadence while software runs on a weekly one, so the mechanical fix you need arrives in six weeks and the workaround becomes permanent.

There is a human tax too. In a big organisation, being wrong is visible and being slow is not, so people gather evidence before acting. In a room of four, being wrong costs an afternoon, so people just try it. That difference compounds across a year of unknowns.

What are the actual choices a small team makes about its software base?

Seven choices cover almost every small robotics team, and picking wrong costs months rather than days. You can adopt the full ROS 2 stack and inherit navigation, drivers and tooling. You can use ROS 2 only for its tools, recording and visualising while your own code does the work underneath. You can live inside a vendor's development kit and accept its limits. You can write one program with no middleware at all, which is right more often than people admit early on. You can buy a commercial platform with support behind it. You can add a cloud layer for fleets you cannot physically reach.

The seventh is a lighter middleware, and the honest description of that category is a message layer without an ecosystem. HORUS sits here: an open-source real-time robotics middleware for Rust, Python and C++ where the three languages share the same shared-memory ring buffers, so messages between processes on one machine are not serialised. Apache-2.0, validated in simulation, and no substitute for ROS 2 when what you actually need is a navigation stack, an arm planner or a driver somebody else already wrote.

How do those choices compare?

Read the last column first.

Does this hold for a research lab as well as a startup?

Yes for the speed, and no for what the speed is worth. A lab of three moves as quickly as a startup of three, and the deadline is a paper rather than a customer, so the reward for shipping early is different. What labs lose is continuity: students arrive and leave on a fixed schedule, and the fastest person this year graduates next year. Speed that produces knowledge nobody can rebuild afterwards is a loan against the next student.

The practical difference is where each should spend its small budget for discipline. A lab should spend it on reproducibility, meaning a recorded run that can be replayed, an environment that rebuilds with one command, and a written note explaining why each calibration number is what it is. A startup should spend it on the path from demo to deployment, meaning safe behaviour when something stops answering and a way to update a machine in the field.

Both fail the same way when they spend it on ceremony instead: process copied from a large organisation, doing coordination work for a team that has nothing to coordinate.

What hardware decisions decide whether a small team stays fast?

Buy everything you cannot debug, and build only the part that is actually your product. A small team stays fast by keeping the number of things that can be wrong low, and custom hardware raises that number in the one dimension you cannot iterate quickly. A custom board that needs a respin puts a manufacturing cycle in the middle of your schedule, and no amount of software cleverness absorbs it.

The choices that keep teams quick look boring from outside. One main computer rather than several, because every extra machine adds a network, a clock and a class of problem that only appears under load. Sensors with drivers that already exist, because writing one is a fortnight you did not plan. An off-the-shelf chassis or arm while the product question is still open. A bench setup that runs everything except the motors, so most days do not need the robot at all.

The exception is real: if the mechanism is your product, build it early and buy everything around it. Whether a robot should run one computer or several covers that split in more detail.

What if you have three months until a demo?

Freeze the software base now and spend the three months on behaviour, because a migration inside a deadline is how teams arrive with a stack nobody trusts. This is the period when the temptation to switch middleware, change language or adopt a simulator you have never run is strongest, since each promises to fix the thing that hurts today. Each also brings a month of unfamiliar failures at the worst possible time.

What pays inside three months is unglamorous. Record real runs so a change can be tested without the robot. Script the demo path end to end and run it daily, because a path run twenty times fails in ways nobody predicted after two. Write the recovery behaviour, so that when the machine loses a sensor it stops in a safe pose rather than continuing confidently.

If you must make one structural change, make it the smallest useful one: separate the code that touches hardware from the code that decides what should happen. That single split is what lets you test decisions on a laptop, and it survives every later choice you make.

What if the team knows Python but not robotics?

Keep Python for the thinking, and buy or borrow everything that has to keep time. A team strong in Python and new to robots usually assumes the language will be the wall, then discovers the wall is timing: a loop that must run when it says it will. Perception glue, policy code, behaviour logic and anything talking to a model are comfortable in Python. A wheel controller holding speed while a camera pipeline runs is not, and that is a boundary rather than a rewrite.

The pattern that works is layered. Buy hardware whose vendor provides the low-level loop. Keep your own Python above it. When something must run on a schedule, move that one piece down into a compiled language and leave the rest alone, rather than converting the project.

The other advice is to spend the first month on the parts nobody films: coordinate frames, units, timestamps, and what happens when a message is late. Those four eat more calendar in a first robot than any algorithm. Middleware options for solo builders and two-person teams walks through the same trade at the tool level.

What does a small team give up to move this fast?

You give up redundancy, written memory and the ability to work on two hard problems at once. One person holds the arm, one holds perception, and when either is ill the robot stops improving in that direction. Nothing dangerous happens immediately, which is what makes it easy to ignore for a year.

The deeper cost is memory. The robot's real behaviour ends up encoded in habits: the order things must be powered, the calibration nobody re-derives, the reason a limit is set where it is. That knowledge is why the arm stops before it hits the table, and none of it is written anywhere. When the person carrying it leaves, the team does not lose code, it loses the reasons, and the next engineer restores the same limit six weeks later after the same broken table.

You also give up parallelism. A small team can chase one hard problem at a time, so a second one does not halve the schedule, it doubles it. Choosing which hard problem to own, and buying your way out of the others, is most of the strategy.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever the shortest path to a working robot runs through work other people have already done. If your machine needs to build a map, navigate a building, plan an arm motion around obstacles or talk to a sensor whose only driver is a ROS 2 package, then the ecosystem is the product and reproducing it is a year you do not have. Recording a run and replaying it, watching the robot's state in a viewer, and a new hire who already speaks the vocabulary are gains that arrive on day one.

ROS 2 also wins when a customer, partner or funder expects it, when the robot spans several computers, and when your collaborators are academics who publish code that assumes it. HORUS is not the answer in any of those cases, and choosing it there means rebuilding tools you could have inherited.

The cost is honest and worth naming: setup and learning before the robot does anything new, a preference for Linux, and behaviour on ordinary Wi-Fi that surprises people. Those are the reasons to look elsewhere, and they are not reasons to look elsewhere when you need the ecosystem.

Is small-team speed just cutting corners?

No, and here is why: most of what a large team does is coordination, and a team of four genuinely does not need it. Design documents that exist so eight people can agree, review chains that exist so nobody ships alone, interface specifications that exist because two groups cannot talk daily — none of that is safety work, and skipping it costs a small team nothing. Copying it anyway is the most common way a fast team becomes a slow one.

There is a second category, though, and it is not optional. A safe state the machine falls into when something stops answering. A watchdog. Recorded runs, so a regression can be found rather than argued about. One command that rebuilds the environment that works. A short note explaining why each unusual number is what it is.

That list is small, cheap, and it protects truth rather than coordinating people. Teams that skip it are cutting corners. Teams that skip the first list are just being small on purpose. Why robotics projects stall after the prototype is mostly a story about the second list arriving too late.

Does hiring more engineers make a robotics team faster?

Partly, but not the way you think. Adding people adds capacity and subtracts shared context, and robots punish lost context harder than most software does, because the failures cross boundaries that an organisation chart cannot see. The new engineer costs weeks of your fastest person's attention before returning any, and during those weeks the robot moves more slowly, not faster.

Hiring genuinely helps when the work splits along a real physical seam. A second robot, a subsystem with an interface that has stopped changing, a test rig somebody can own completely — these divide cleanly. Hiring hurts when three people are added to the same integrated loop, where each change touches everyone and the meeting appears to coordinate them.

The useful test before hiring is to ask what the new person could own on their first month that nobody would have to be consulted about. If the honest answer is nothing, the constraint is not headcount. It is that the robot is one tightly wound machine, and the next gain comes from separating a piece of it, not from adding another pair of hands to the middle.

How do you decide what to change first?

Look for the place where the same conversation keeps happening, because that is where your structure is missing, and change only that. If integration keeps surprising you, the fix is running the whole robot more often, not a new framework. If the robot behaves differently on Tuesday than it did on Monday, the fix is a recorded run and a rebuildable environment.

The mistake is answering an organisational problem with a technical migration, which feels productive and buys nothing. Change the software base only when the base itself is the thing generating the conversations.

• If your robot needs maps, planners or a vendor's driver -> ROS 2, because the ecosystem is most of the machine.
• If your robot is your own code on one computer -> keep it simple, because a framework adds learning and no capability.
• If perception, planning and control now crowd that one computer -> a shared-memory message layer, because the boundary between them is the expensive part.
• If a demo is close -> change nothing structural, because new plumbing brings new failures at the worst moment.
• If the same question keeps needing one specific person -> write down their reasons, because that is the bottleneck you actually have.

When two options stay close, weigh them on the five axes of the HORUS Fit Framework — ecosystem size, setup effort, team size fit, deployment target, and licence — and take the one that loses on the fewest. No scores, just five honest questions about your situation rather than about the software. And if the crowded computer turns out to be your problem, star HORUS on GitHub so it is in your list when you start building.