What Investors Ask About a Robotics Team's Software Choices

Investors almost never ask whether you picked ROS 2 or something like HORUS; they ask who owns your stack and what changing it costs. The reason is that a framework is a reversible decision and a team's judgement is not, so diligence probes how the choice was made rather than what it was. That flips the moment your stack is the product you are selling. This post is for founders and engineers who have a diligence call in the calendar and want to know which software answers actually move the conversation.

You have a call on Thursday with someone who has funded four robotics companies and read the deck twice. The deck is fine. What worries you is the twenty minutes at the end, when a technical partner joins and starts asking about the software, because nobody on the team agrees on what a good answer sounds like. One person thinks you should say you use the standard stack, because that sounds safe. Another thinks you should say you built your own, because that sounds like a moat. Both are guessing.

Meanwhile there are things in the repo you would rather not explain. A settings file nobody fully understands, edited by three people, one of whom has left. A vendor driver you patched and never sent upstream. A demo that works on the bench and needs one specific engineer in the room to work anywhere else. You know which parts of the system you are proud of and which parts you cross your fingers about, and you suspect the person joining on Thursday has seen both before, in that order, from four other teams.

Do investors actually care which robotics framework you chose?

Investors care about what the choice implies, and almost never about the name on the box. Nobody at a fund has a favourite message transport. What they have is a list of ways robotics companies quietly stall, and your stack becomes interesting only where it touches that list: a decision only one engineer can explain, a dependency whose commercial terms can change, a rewrite hiding inside the roadmap, a demo that travels badly.

So the question behind every software question is the same one. If the person who made this decision left next month, could anybody else defend it? Teams that answer well usually wrote the reasoning down at the time, in a paragraph, naming the option they rejected and the reason. Teams that answer badly use the word standard a lot, or the word clean, and cannot say what either bought them.

The trap is treating the meeting as a technology comparison and preparing accordingly. It is not one. It is an evidence check on how your team makes decisions that are expensive to reverse, and the software stack is simply the example closest to hand.

What counts as a software choice in a robotics company?

A software choice is anything that would take more than a sprint to undo, which is a much shorter list than the repository suggests. Your planner is not one, because a planner can be replaced by a better planner in a fortnight. Your message layer is one, because every process touches it. So is the language your control code lives in, the operating system your board runs, the simulator your tests assume, the log format your tools read, and the licence attached to everything you did not write.

The pattern is that reversible choices are about algorithms and irreversible ones are about interfaces. An investor with robotics experience knows this without being told, which is why the conversation skips your clever bits and lands on the plumbing you find boring.

There is a second category that founders forget entirely: the choices you made by not choosing. Nobody decided that the perception process and the control process would share one machine, or that the demo would only run on the laptop with the patched driver. Those are still choices. They are simply undocumented ones, and they are exactly what a stack decision quietly locks you into.

What are the realistic stack options a robotics team defends in a meeting?

There are about seven answers a robotics team can give, and six of them are defensible. You can build on ROS 2, which carries navigation, mapping, visualisation, recording, simulator integration and vendor drivers, and which every candidate you interview will already know. You can keep ROS 2 and move one deadline-critical loop onto a shared-memory middleware such as HORUS, where Rust, Python and C++ share the same ring buffers so messages between processes on one machine are not serialised; it is Apache-2.0, open source, validated in simulation, and explicitly not a replacement for the ecosystem sitting above the transport. You can build on the SDK of the robot you bought, which is fastest until the vendor becomes your competitor. You can buy a commercial real-time framework, which makes sense when an external auditor will read your paperwork and someone else is paying. You can write your own transport, which is defensible only when the transport is what you are selling. Or you can run the whole robot as one program, which is the right answer far more often than anybody admits in a pitch meeting.

How do the stack options compare from the other side of the table?

Read the last column first, cross out every row that describes your situation, and see what survives. That is roughly the exercise a technical partner runs in their head while you are still talking.

Notice that none of those columns is about speed. Diligence is about who carries which risk, and for how long.

What does a weak answer about software sound like in a diligence call?

A weak answer is one that describes a preference where a problem should be. The classic version is architectural: the old stack was messy, the new one is clean, the team feels better about it. An experienced listener hears an unbounded cleanup competing with the roadmap, because cleanup has no finish line.

The second weak answer is the appeal to authority. Everybody uses it. That answer survives exactly one follow-up question, which is usually whether everybody using it has your update rate, your board and your customer.

The third is the moat claim without a mechanism. Custom plumbing described as defensible technology, with nothing said about what it does that an existing option could not. Nobody is against custom work. They are against paying for maintenance that buys no advantage.

Strong answers share a shape. They name a behaviour, not a feeling: the gripper closed late whenever the camera process got busy, we tried the obvious three fixes, the third worked, here is what it cost. That answer takes forty seconds and ends the topic.

Are you a research spin-out, a seed-stage startup, or a scaling product company?

Three companies with identical code get asked three different sets of questions. A research spin-out gets asked whether the software can leave the lab: whether anyone outside the founding team has built it, whether the results depend on a machine under someone's desk, whether the licence on the university code allows selling anything at all. That last one has killed more spin-out deals than any technical finding.

A seed-stage startup gets asked about focus. The concern is not that the stack is wrong but that the team is spending months on something that no customer will ever notice, and the tell is a roadmap where infrastructure work has no end date attached.

A scaling product company gets asked about the third year. Who patches the thing at eleven at night during a customer trial. What happens when your one systems engineer resigns. How software reaches the units already in the field. What the licence does when a larger company buys you. At that stage the questions stop being about building the robot and start being about owning a fleet of them, which is a different conversation with different evidence.

Does the hardware you build on change what investors ask?

The hardware narrows the questions faster than anything you say about the software. If you build on a humanoid or quadruped you bought, the whole conversation becomes about the vendor: what the terms say, what happens when the SDK changes under you, whether you can move to different hardware without starting again, and whether the vendor is drifting toward selling what you sell.

If you designed your own machine, the questions move to the compute box and the split. One board with several processes sharing it is a normal, defensible arrangement, and the follow-up is simply how those processes behave when the machine gets busy. Several boards on a network invites a different set of questions about the link, because nothing you do locally helps a message that has to cross a cable.

If the tight loop lives on a microcontroller beside the motor, the middleware discussion mostly evaporates, and attention moves to the boundary: what runs on the small board, what runs on Linux, and who decided which is which. That boundary is usually where the surprises live.

How close are you to revenue, and how does that change the questions?

Distance from revenue changes which risks a listener is willing to accept. Pre-product, the stack is almost uninteresting; what matters is how quickly you can put a working machine in front of somebody. Nobody will fault a team for choosing the option with the most existing packages and shipping something crude.

At first customers, the questions turn to whether the demo travels. Does the robot work in a building nobody prepared, on a network nobody controls, with a person who has not been trained? Software choices become visible here for the first time, usually as the reason something works in the office and not in a warehouse.

At scale, the questions become unglamorous and expensive: updating deployed units, reading logs from a machine you cannot touch, reproducing a fault a customer saw on Tuesday. This is where teams pay for choices made two years earlier by nobody in particular, and the pattern is well worn enough that prototypes failing to survive production is its own genre of post-mortem.

What does your team need to know to answer these questions credibly?

You need one person who can open the layer underneath your own code and form an opinion about it, and you need that person to not be the only one. Day-to-day robot code looks much the same whichever stack you chose. The credibility gap appears below your own code, at the moment something fails in a dependency and somebody has to read it.

That is why the ownership question gets asked in commercial language rather than technical language. Can you fix this yourselves is a question about staffing, not about source availability. A team of six with one person who understands the transport is a team with a single point of failure, and everyone in the room knows it.

The practical fix is boring and works. Have a second person walk the architecture without the first person in the room. Write the decision paragraph. Keep a document listing every dependency, its licence, and what you would do if it stopped being maintained. That document takes an afternoon and answers a surprising share of the questions you are dreading.

What do you give up by picking a stack that reads well in diligence?

Optimising the stack for a meeting costs you the specific advantage that made the meeting worth having. The safe answer, meaning the one nobody argues with, is usually the widest ecosystem, and the widest ecosystem is built for the general case. If your product depends on motion that feels different from everyone else's, the general case is exactly what you cannot afford.

You also give up speed in a subtler way. Teams that choose to look conventional often keep a stack that is a poor fit and then spend engineering months working around it, and that cost never appears in any document. It appears as a roadmap that slips by a month, repeatedly, for reasons that are always different.

The reverse trade is real too. Choosing something unusual means new hires arrive not knowing it, contractors take longer, and your error messages return nothing when searched. Neither trade is wrong. What is wrong is making it without noticing, then discovering the price during the quarter you can least afford it.

When is ROS 2 the better choice?

ROS 2 is the better choice for most robotics companies raising money, and HORUS is not the answer when what you need is an ecosystem rather than a transport. If your robot must map a building and navigate it, use the stack that already solves that; re-deriving navigation is a career, not a sprint. If your sensor vendor ships a driver, use it. If you are hiring quickly, hire into something people already know, because onboarding time is real money at a small company.

There are quieter cases. Research-adjacent companies whose work must be reproduced by partners or reviewers need the shared vocabulary more than they need anything else. Robots split across machines are limited by the network, and no local change touches that. Robots that are simply not in a hurry, which is most robots, have never had a message-timing bug and never will.

And the most common case: a team whose complaints, examined honestly, are about their own code. No stack change fixes a controller, a calibration, or backlash in a gearbox.

Does choosing an unusual framework hurt your fundraise?

No, and here is why: the framework is not what gets scored, the reasoning is. Investors have seen companies succeed on ROS 2, on vendor SDKs, on custom stacks and on a single Python program held together by conviction. What they have not seen succeed is a team that cannot explain why, because that failure predicts every other decision the team will make.

What actually hurts is a mismatch between the choice and the story. A company selling a general-purpose service robot that has written its own transport has some explaining to do, because the plumbing is not what customers buy. A company whose entire pitch is motion quality that competitors cannot match, running the most common stack unchanged, has the same problem in reverse.

The second thing that hurts is a choice with no owner. If the answer to who picked this is a shrug, or a former employee, the conversation stops being about software. It becomes about whether decisions at your company get made or merely accumulate, and that question is much harder to recover from.

Is technical due diligence really an audit of your source code?

Partly, but not the way you think: someone may read your code, but the reading is a sampling exercise, not an audit. Nobody has time to review a robotics codebase properly, so a technical reviewer takes shortcuts that are shockingly effective. They clone the repository and try to build it. They read the commit history for the last two months and see what the team actually spends time on. They open the newest test and the oldest one. They ask one engineer, not the founder, to explain a subsystem.

What that samples is habits, not correctness. A repository where the last eight weeks of commits are all plumbing tells a story regardless of how good the plumbing is. A clean checkout that does not build tells a bigger story than a hundred style problems.

The useful preparation is therefore not cleaning code. It is making sure the boring things work: build from scratch, record a run and replay it, kill one process mid-motion and see what the robot does. Those are the same checks that decide whether you enjoy your own third year.

How do you decide what to lock down before the next raise?

Decide by writing down the two or three choices you would regret being unable to reverse, and then leave everything else alone. For most robotics teams that list is short: the message layer, the language your control code lives in, and the licences on anything you did not write. Everything else can move later without drama, and pretending otherwise is how teams spend a quarter standardising things nobody was going to change anyway.

Then do the cheap work that makes any answer credible. Write the decision paragraph for each locked choice, naming the alternative and the reason. Build the dependency list with licences beside it. Make a second person walk the architecture. Put a date on any infrastructure work sitting in the roadmap, because open-ended infrastructure work is the single most reliable way to lose a technical partner's confidence.

If some of that work is real, plan it as work rather than as a background hum. Teams that treat this as a scheduled task, the way they would budget time for integration, tend to arrive at the meeting with answers instead of apologies.

Here is the whole decision in five lines.

• If you are pre-product and pre-revenue -> pick the widest ecosystem, because the risk that matters is not shipping at all.
• If your pitch is motion quality customers can see -> own the loop that produces it, because that is the thing being bought.
• If you build on a robot you purchased -> read the vendor's terms first, because the terms are the real dependency.
• If one engineer is the only person who understands the stack -> fix that before the meeting, because a single point of failure is a commercial finding, not a technical one.
• If your last two months of commits are all plumbing -> say so plainly and give it an end date, because the alternative is being found out.

The HORUS Fit Framework compresses the rest into five axes: ecosystem size, setup effort, team size fit, deployment target, and licence. Score every candidate on all five, and be able to name the axis you cannot afford to lose, because that is the sentence the room is waiting for. If the timing axis is the one your team keeps circling back to, put HORUS on the reading list rather than the roadmap: star it so it is in your list when you start building.