Robotics Consulting vs Building In-House: How to Decide

Build the software in-house when the robot's behaviour is what your company sells, and hire a consultancy when the robot is a tool for a business you already run. A consultancy delivers a working machine faster than you can hire a team, but hands back software your own staff must own for years afterwards. That flips when the robot's behaviour is the product, whether you build on ROS 2 or something narrower like HORUS. The rest of this post is for a team deciding who writes the next year of robot software, and how to keep the answer reversible.

You have a robot that half works and a quarter that has already gone. The demo runs on one machine, in one room, when a particular person is in the building. Somebody senior has started asking when it will be in front of a customer, and nobody knows, because the last three months went into things that were supposed to take a week.

Meanwhile the recruiter has sent four CVs in six weeks and two of those candidates wanted more than your head of engineering earns. The one strong candidate took another offer on a Friday. There is a firm in your inbox saying it has done this exact thing three times, can start next month and will hand you a working system by spring.

So the argument in the room is not really about software. It is about whether you are buying time or buying a problem, and whether the people who understand your machine in two years will work for you or for somebody else.

Should you hire a robotics consultancy or build the software in-house?

Build in-house when the robot's behaviour is what your company sells, and hire a consultancy when the robot is a tool serving a business you are already in. That distinction settles more of these arguments than any spreadsheet, because it decides whether the software is an asset that compounds or a cost that should be finished and forgotten.

A company selling picking machines to warehouses is selling behaviour. Every improvement in how the arm recovers from a missed grasp is worth money next quarter and the quarter after, and each has to come from somebody who will still be there. A food producer automating one line in one factory is not selling behaviour. That company needs the line to work and documented, and would rather not run a software department.

Most companies sit between those poles. The question that cuts through the middle cases is whether you expect to be changing this software in three years. If the answer is yes, somebody on your payroll has to understand it, whoever writes the first version.

What does robotics consulting actually cover?

Robotics consulting is four different businesses wearing one word, and confusing them is where most bad engagements begin. The first is systems integration: a firm takes a defined job, buys the hardware, writes the software and hands back a machine that does the job. The second is staff augmentation: contract engineers sit in your standups and write code in your repository under your direction. The third is advisory: a short, expensive engagement where somebody experienced tells you which stack, which sensors and which order to do things in, then leaves. The fourth is vendor services, where the company that sold you the arm also sells the engineering to make that arm do your particular thing.

They fail in different ways. Integration fails when the handover is a zip file and a slide deck. Augmentation fails when nobody on your side is senior enough to direct it. Advisory fails when the advice is correct and nobody executes it. Vendor services fail on the day you outgrow the vendor.

Decide which of the four you are buying before the first call, because the proposals all look alike from outside.

What are the real options besides hiring a firm or hiring engineers?

There are six, and the two people argue about are the extremes. A systems integrator delivers a finished machine. A specialist consultancy builds part of it alongside you. Contract engineers work inside your team on your terms. Your own team builds on a large ecosystem, meaning ROS 2, which brings drivers, visualisation, recording and a pool of people who already know it; or your own team builds on something narrower, such as HORUS, an open-source middleware where Rust, Python and C++ processes on one machine exchange messages through shared memory instead of serialising them, which suits a robot whose difficulty is a tightly timed loop rather than mapping an unfamiliar building. Or the vendor who sold you the hardware does the work.

Notice that the delivery model and the technical stack are separate choices companies keep welding together. The pairing that hurts is a firm building on something only that firm uses, because the handover then includes a permanent dependency on the company you were hoping to stop paying.

How do the delivery options compare side by side?

The comparison turns on the column most people skim: what each arrangement assumes you already know. An engagement that assumes a senior robotics engineer on your side is a bad engagement if you do not have one, however good the firm is.

No row wins. Pick the row whose final column does not describe your company.

Which option fits a hardware company compared with a software-first startup?

A hardware company should buy software help early and hire it later, and a software-first startup should do the reverse. The reason is where each keeps its scarce attention. A hardware company's founders are in the machine shop, and software is real work nobody senior has time to supervise, and unsupervised software written by a first hire with no one to review it is the most expensive kind.

A software-first startup has the opposite shape. There is capacity to review, opinions about architecture and people who will still be there in two years, but no experience of hardware that lies to you. That company should hire, and buy a short advisory engagement to shorten the part where everybody learns that sensors have opinions.

Hardware companies hire one robotics engineer and leave that person alone with the whole stack. Software companies hire a firm and then argue with every decision it makes. Neither arrangement produces a machine, and both take a year to reveal it, which is one of the patterns behind projects that stall after the prototype.

Does the hardware you have already bought narrow the choice?

Yes, usually more than the budget does. The arm, mobile base or humanoid you already ordered arrived with an SDK, and that SDK was written against assumptions about how the rest of your software is organised. If the vendor ships drivers for one ecosystem only, choosing a different one means somebody ports drivers, which is unpaid work no customer will ever see and no consultancy quotes accurately.

Hardware narrows it a second way. If the machine is really several computers on a network, the network becomes the constraint that overrides everybody's preference, and people who have handled dropouts and reconnection on real sites are worth renting. If the machine is one capable board running everything, the problem is smaller than the proposals suggest, and a good contractor plus your own lead may cover it.

If the compute is a microcontroller with no real operating system, most firms pitching robot platforms are pitching the wrong thing entirely, and you want firmware people. Ask what the target computer is before anyone quotes.

How much does your deadline change the answer?

A deadline inside two quarters points at outside help, because hiring is slower than any plan assumes. Opening a role, filtering candidates, waiting out a notice period and then waiting again while the new engineer learns your machine consumes most of a year, and a team with a spring demo does not have that year.

Deadlines also distort judgement in one predictable direction. Under pressure, hiring feels like the responsible choice because it builds something permanent, while paying a firm feels like an admission of failure. A permanent asset is worth nothing if the company misses the window that funds it.

The reverse case is real. If your runway is long and the robot's behaviour is the product, a slower in-house build is the correct investment even though it looks worse in this quarter's update. The tell is whether you can name what your machine must do better than everybody else's, which is the same logic as deciding what to build and what to adopt.

What if nobody on your team has shipped a robot before?

Buy experience before you buy code. A team that has never put a machine in front of a customer does not yet know which problems are hard, and a short advisory engagement fills that gap better than a long build contract. The value is not the recommendation. It is somebody saying, in week two, that the thing you scheduled for a fortnight is a quarter, and the thing you were dreading is a Tuesday.

The trap for inexperienced teams is buying a finished machine and calling it a foundation. The machine works, it is delivered, everybody applauds, and then the first change request arrives and nobody internally can make it, and the company pays the same firm again for a change an internal engineer would do in a day.

If you buy a build, insist that one of your own engineers works inside it from the first week, reviewing merges and running the setup from a clean checkout. That single condition is the difference between buying a machine and buying a capability.

What does the wrong choice look like a year later?

It looks like a working robot nobody in the building can change. The demo runs, the customer is pleased, and every request that follows becomes a scoping conversation with an outside firm. Your engineers can describe what the software does but not why, because the reasons live in a chat workspace you were never in and in the head of a contractor now working for somebody else.

The in-house version looks different and takes longer to diagnose. There is a stack only your team uses, a configuration format one person invented, and a build that works on the machine of whoever wrote it. Onboarding takes weeks, standups fill with plumbing rather than behaviour, and the robot's actual job gets whatever hours are left.

To tell the two apart, ask where last month's engineering hours went. If they went to the machine's job, the arrangement is fine whoever is doing the work. If they went to configuration and reproducing failures nobody can explain, the arrangement is the problem.

What do you give up when an outside firm writes your first robot stack?

You give up the understanding that comes from having built the thing, and that loss shows up much later than the invoice does. Every hard decision during a build teaches somebody something: why the calibration runs in that order, why one sensor is ignored for the first second, why a retry exists in an odd place. When a firm makes those decisions, the knowledge leaves when the firm does, even though the code stays.

You also give up speed on small changes. An internal engineer who knows the system changes behaviour the same afternoon somebody asks. An external arrangement turns the same change into a scope, a quote, a slot and a delivery, which is not the firm being difficult but what happens when the people who understand the machine are not in the room where the request appears.

The mitigation is not refusing outside help. It is keeping one internal engineer close enough to the work to rebuild it, and requiring the boring handover artefacts, which is the same discipline described in onboarding an engineer onto a robot codebase.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever the hard part of your machine is perception, navigation, integration or being maintainable by a team whose members change over time, and that describes most robots consultancies are hired to build. If the robot must map a building it has never seen, plan around a person who walks in front of it and talk to a fleet manager, ROS 2 is years of work you get to skip rather than a compromise.

ROS 2 also wins on the boring axes that decide who can keep a machine alive. You can hire people who already know it, a consultancy can staff your project without inventing anything, vendors ship drivers for it, and a failed run in a customer's building can be replayed at a desk in your office the next morning.

HORUS is not the answer in those cases. A shared-memory middleware moves messages between processes on one computer and brings no mapper, no planner, no fleet interface and no driver for the lidar that arrived last week. If those are your hard problems, choosing something smaller means somebody writes all of them, and that somebody bills you by the day.

Is hiring engineers always cheaper than paying a consultancy?

No, and here is why. The comparison people run puts a day rate next to a salary and concludes that the salary wins. A salary is the smaller part of an employee's real cost, and a new engineer produces nothing for the first stretch while learning your machine, your customer and the particular way your hardware misbehaves.

The larger omission is the cost of being late. A firm that has built four machines like yours starts on the third week of the problem rather than the first, and that difference lands in your calendar rather than your budget. If being six months late means missing the pilot that funds the next round, the day rate stops looking expensive.

Where hiring genuinely wins is the second year and everything after. Consulting cost is roughly flat: the same rate buys the same day of work in year three. An employee's value compounds, because that person now knows why the machine does what it does. The honest framing is rented speed now against owned speed later.

Do you lose control of your codebase when an outside firm writes it?

Partly, but not the way you think. The ownership question is the easy part and gets settled in the contract, and any competent firm agrees to it without argument. Companies fixate on that clause and then lose control through a door nobody was watching.

What you actually lose is the ability to change things without asking. The code can be entirely yours and still be unmaintainable by your staff, because control is not a legal state. It is whether an engineer of yours can check out the repository on a clean machine, build it, run the robot, break something and understand the failure. If that is not true, you own a codebase the way you own a language you cannot read.

The fix is procedural rather than legal, and costs almost nothing when agreed at the start. Work happens in your repository from day one. An internal engineer reviews merges even if that review is slow at first. The setup runs from a clean checkout on your hardware once a month, by one of your people.

How should you make this call in a week rather than a quarter?

Write one sentence describing what your company sells, and let the sentence decide. If the sentence is about a service your robot enables, buy the robot's software and spend your attention on the service. If the sentence is about what the machine itself does better than anything else, the behaviour is your asset and it belongs to people who work for you.

Then run one cheap test before committing to anybody. Give the shortlisted firm, or the candidate you are close to hiring, the ugliest small piece of your real problem on your real hardware, paid, for a fortnight. Watch what happens when the sensor misbehaves, and notice whether you are told about problems early or told everything is fine until it is not.

Whichever way you go, write the decision down with its reason, in the repository, and name the condition that would reverse it. Companies rarely regret the choice itself; they regret that nobody recorded why it was made, so the next argument starts from scratch. The failure modes underneath these arguments are catalogued in what companies get wrong about their software foundations.

• If you are automating one line in a plant you own -> a systems integrator, because the machine is a tool that should be finished and documented.
• If the robot's behaviour is what customers pay for -> build in-house, because every future improvement has to come from somebody who stays.
• If you have a strong lead engineer and no headcount -> contract engineers under your direction, because direction is the scarce ingredient.
• If you have funding, a date and no robotics experience -> a specialist firm with a named handover milestone, because experience is faster to rent than to hire.
• If the real argument is who owns the machine's knowledge in two years -> settle that in writing before choosing anybody.

The HORUS Fit Framework reduces the technical half of this to five axes: ecosystem size, setup effort, team size fit, deployment target, and licence. Score every stack a firm proposes on all five, and reject anything weak on the axis your company cannot afford to be weak on.

If timing between processes keeps turning out to be that axis, put HORUS on your reading list rather than on this quarter's plan: star it so it is in your list when you start building.