How to Run a Robotics Project With Two Engineers

With two engineers, adopt ROS 2 only when its catalogue does real work; otherwise run a smaller middleware or none at all. Two people can carry one robot and one stack, so what you refuse to build matters more than what you adopt, and a single-machine layer such as HORUS fits when the catalogue goes unused. The verdict flips the moment a third engineer joins. The rest of this post is for two engineers deciding once, early, how to divide a robot project neither of you has spare hours to redo.

There are two of you and there is one robot. Some weeks that feels like plenty. Then comes the week where the robot is on your colleague's desk, the branch that works is on your colleague's laptop, and you are writing code you cannot run. Integration slides to Friday, then to the Friday after. Each of you owns a half the other half does not fully understand, and when one of you takes a week off, that half of the robot stops moving. Progress is real but invisible: the demo looks the same as last month because everything you did was underneath. Somebody asks for a schedule and neither of you can give an honest one, because most of the time went into work nobody asked for and everybody needed — a build that reproduces, a way to see what the robot is doing while it does it, a rule for what happens after a crash. The question underneath is not whether two people can build a robot. Two people build robots all the time. The question is which of the many things you are currently doing you should stop doing.

How should two engineers actually run a robotics project?

Two engineers should run one robot on one computer with one stack, and should decide in the first week which half of the problem they are not going to solve. Everything else follows from that. Two people have roughly one person's worth of attention left after the robot itself, so every extra axis — a second board, a second language nobody knows, a second deployment target, a custom message layer — is charged against the only resource that is genuinely scarce. The teams that ship with two people are not the clever ones; they are the ones that said no early and in writing. The teams that stall are usually doing excellent work on four fronts at once, none of which is finished. That means the first decisions are subtractive: what hardware you will not support, what generality you will not build, what part of the stack you will adopt rather than write. Make those in week one, write them down where both of you can see them, and revisit them only when something changes in the robot rather than in the mood.

What work exists in a robot project no matter who does it?

Every robot project contains the same body of unglamorous work, and it is far larger than the part that makes the robot move. There is hardware bring-up: motors that spin the wrong way, a sensor whose cable order is undocumented, power that browns out under load. There is the build and environment, which must reproduce on a second machine or the project silently becomes one machine. There is plumbing between the parts. There is starting six things together and stopping them together. There is recording a run and replaying it at your desk, because you cannot debug a robot by watching a robot. There is seeing what is flowing while the machine moves. There is calibration, which nobody schedules and everybody redoes. There is a rule for what the robot does when a part goes quiet. Then, after all of that, there is the behaviour you actually wanted. Two engineers who plan only the last item will spend most of the year on the others and feel like they are failing while doing entirely normal work.

What are the real options for dividing the work and the stack?

There are two questions, and most teams answer only the first. The first is how you divide: both of you full-stack across a shared codebase, split by layer with a written interface between, split by hardware and software, or one person building while the other integrates and deploys. The second is what carries the division, and here the field is short. ROS 2 gives you a message layer, a build system and a catalogue of drivers, planners and visual tools, adopted as one decision, which is worth a great deal when you use the catalogue and expensive when you do not. A single-machine middleware such as HORUS is the lighter end: an open-source Apache-2.0 layer where Rust, Python and C++ share the same shared-memory ring buffers, so a two-language robot on one board is not paying to convert data between the languages, with no package catalogue included. Below both sits no middleware at all, which stays correct much later than people admit. Above both sits a vendor platform, where the robot's software model is chosen for you.

Which arrangement fits which kind of two-person team?

The arrangement that fits is the one whose assumptions match the robot you are building this year, not the company you intend to become.

What breaks first when two engineers share one robot?

The first thing to break is access to the robot, and it breaks earlier than any technical problem. One physical machine plus two engineers means one of you is always writing code you cannot run, and code that has not run against hardware accumulates wrong assumptions quietly. The second thing to break is the environment: a fix typed into one terminal on a Tuesday never reaches the other laptop, so within a month the robot works on exactly one computer and neither of you is quite sure why. The third is the interface between your two halves, which was agreed verbally in week two and has drifted since, so integration day becomes a day of discovering the drift rather than a day of running the robot. The fourth is knowledge: each of you becomes irreplaceable in a different area, and the project acquires two single points of failure who take holidays. None of these show up in a design review. They show up as a schedule that keeps moving by a week.

Are you two founders, two engineers in a company, or two researchers?

The right answer changes with who is paying and what counts as done. Two founders should optimise for a working demo on real hardware and should adopt aggressively, because a stack you did not write is a stack you did not have to maintain during the months you are trying to prove the idea. Two engineers inside a larger company should optimise for handover, because a third person will eventually be assigned, and choosing something nobody else in the building knows converts your project into your permanent job. Two researchers should follow the stack their field publishes with, since reproducing other people's results is most of the work and an unusual choice makes that harder. Two people building a product for customers should decide the licence question before writing any code, because what the licence actually allows you to sell quietly removes candidates from the shortlist and is expensive to discover after a year of building on the wrong one.

Does having only one robot between two engineers change the plan?

Yes, and it changes it more than the choice of framework does. With one machine and two people, the scarce resource is hardware time, so the plan should be built around keeping both engineers unblocked when only one has the robot. That means a simulator good enough for the boring half of the work, even if the physics is not convincing, because most of what you debug is plumbing rather than dynamics. It means recording real runs constantly and replaying them at the desk, so the person without the robot is still working against real data instead of imagination. It means a second, cheaper target — a spare board, a bench rig with one motor — so hardware questions do not queue behind each other. Teams that skip this end up with one engineer who owns the robot and one who owns the parts of the codebase that never touch it, which is the division that later makes handover impossible and holidays stressful.

How does the deadline change what two engineers should build?

A near deadline should make you adopt more and build less; a distant one should make you write down the interfaces first. If a demo is weeks away, take whatever exists, accept its shape, and spend your hours on the specific thing the demo needs to do, because with two people there is no parallel track where the proper version quietly gets built. If the horizon is a year, spend the first week on the two decisions that are expensive to reverse — what carries messages between the parts, and where the line between your two halves runs — since middleware decisions are hard to undo once a year of code assumes them. If there is no deadline at all, invent one, because two-person projects rarely fail from a wrong technical decision; they fail from a slow, reasonable drift where every month is productive and nothing ever ships. A fake demo date to an audience of five friends fixes more schedules than any planning tool.

What skills do two engineers need to cover between them?

Between two people you need five areas covered and only three covered deeply. Someone must be comfortable at the hardware boundary: wiring, power, reading a datasheet, recognising a brown-out rather than blaming the code. Someone must be comfortable with the systems layer: Linux, processes, builds, why the robot only starts when you run the commands in one particular order. Someone must own the behaviour itself, the control or the planning or the model, whatever makes your robot yours. The two areas that need only shallow cover are visualisation and deployment, which are worth adopting rather than mastering. The gap that hurts most is the systems layer, because it is nobody's favourite and it is where a two-person team quietly loses its evenings. If neither of you enjoys that work, weight your stack choice heavily towards whatever asks for the least of it, even at the cost of features you can see in a comparison table.

What do you give up by running a project with two people this way?

You give up breadth, and you have to give it up deliberately or you lose it by accident. A two-person team that says no early ends up unable to support a second robot variant, unable to promise a feature outside the chosen path, and unable to answer yes to reasonable requests from whoever is funding the work. That is the trade, and it is a real cost rather than a rhetorical one. You also give up some depth of understanding, because adopting a stack means shipping on top of code you have not read, and the day it misbehaves you will be debugging somebody else's design at the worst possible moment. And you give up optionality: the interface you agree in week one will feel wrong by month six, and changing it costs both engineers a week, which is why it should be small and written down rather than large and assumed. In exchange you get a robot that exists, which no amount of preserved flexibility provides.

When is ROS 2 the better choice?

ROS 2 is the better choice for a two-person team whenever the catalogue replaces work you would otherwise do. If the robot needs mapping, localisation, a navigation stack or a driver for a common sensor, ROS 2 hands you components thousands of people have debugged, and two engineers cannot rebuild those in any timeframe that matters. ROS 2 is also the better choice when the robot spans several computers, when the team expects to grow, when hiring is on the horizon and the stack a candidate already knows saves months, and in any lab or course where the shared vocabulary is the point. HORUS is not the answer in those cases, and picking it there means writing drivers instead of a robot. The honest boundary is that ROS 2 charges setup time and pays back ecosystem, so a two-person team that never opens the catalogue is paying the bill without collecting. Teams weighing this specific call in more detail should read whether a two-person team should adopt ROS 2.

Should two engineers write their own middleware instead of adopting one?

No, and here is why. The part you would write first — sending a message from one program to another — takes an afternoon and works. The parts you would write over the following year are the ones that make it usable: starting everything together, noticing when one part dies, recording and replaying a run, seeing what is flowing while the robot moves, versioning message shapes so an old recording still loads, and deciding what each consumer does when its input goes quiet. Two engineers who build all of that end up with a private framework nobody else can debug, at exactly the moment they want to hire a third person. The exception is narrow and real: if your robot is one program in one language with a handful of threads and no crash boundary, you do not need middleware and adopting one adds ceremony for nothing. The failure mode is not skipping middleware. The failure mode is building one accidentally, a socket at a time, while believing you skipped it.

Would a third engineer fix a two-person project that is behind?

Partly, but not the way you think. A third engineer helps enormously with breadth — hardware bring-up, deployment, the systems work neither of you enjoys — and helps very little with the thing that is actually late, which is usually one deep piece only one person understands. For a while the third person makes the schedule worse, because both existing engineers spend their weeks explaining a system that was never written down, and the parts that were verbal agreements now have to become real ones. The teams that absorb a third person smoothly are the ones who already had a reproducible environment, a written interface and a stack somebody outside the team could plausibly know, which is why what a small team standardises early matters more than how many people it has. If your project is behind because of scope, adding a person adds scope. Cut first, hire second.

How do you decide all of this in one afternoon?

Write three lists and let the lists decide. First, everything in the robot you were never going to write yourselves, named specifically rather than by category: not "some driver stuff" but the actual sensor, the actual planner. Second, how many computers and how many languages the finished robot contains. Third, the two or three things you are choosing not to do this year, written where both of you can see them. A long first list means adopt ROS 2 and accept the upkeep, because that catalogue is the only thing here that takes years to replace. A short first list plus one computer and two languages means a lighter layer where those languages share memory, and the evenings you keep are the point. A short list plus one language and one program means no middleware yet. Then, before any robot code, write the setup script that rebuilds a working machine from blank. If you cannot write that script, you have learned something important about whether the stack fits two people.

A short version, by situation:

• If you are two founders proving an idea on real hardware -> adopt the heaviest stack whose catalogue you will actually use, because maintenance you avoid is runway you keep.
• If you are two engineers inside a bigger company -> ROS 2, because a third person will be assigned and the stack they already know is worth more than any technical edge.
• If your robot is one board running several languages -> a layer where those languages share memory, because converting data between them is a cost you pay every cycle forever.
• If neither of you enjoys build systems and Linux plumbing -> whatever installs from blank in one evening, because that is the stack still running next spring.
• If one of you owns the robot and the other cannot run the code -> fix hardware access before choosing anything, because no framework repairs a team that cannot both test.

When you want to compare options rather than symptoms, the HORUS Fit Framework lines them up on five things that are not numbers: ecosystem size, setup effort, team size fit, deployment target, and licence. For two engineers, setup effort and team size fit outrank the rest, and licence quietly eliminates several candidates before the technical argument begins. If the split of work is what you are really deciding, read next about how the parts of a robot run side by side.

The repository is open source under Apache-2.0 and linked below. Star it so HORUS is in your list when you start building.