Outsourcing ROS 2 Development: 15 Questions to Ask a Robotics Software Partner

TL;DR: Before you sign a contract for ROS 2 development services, you need answers to a specific set of questions covering ROS 2 version and DDS experience, testing and CI practices, documentation standards, code ownership and licensing, post-deployment maintenance, and access to real test hardware. This checklist of 15 questions gives you a structured way to evaluate a robotics software partner, compare proposals on technical substance rather than slide decks, and avoid the two most common failure modes: code that only runs on the vendor’s laptop, and a stack you cannot maintain after the engagement ends. The questions also map to three common engagement models – fixed scope, time and materials, and embedded team – each with different risk profiles.

Why does outsourcing ROS 2 development fail more often than it should?

ROS 2 projects fail in predictable ways. A team delivers a demo that works on one specific robot, on one specific network, with one specific ROS 2 distribution. Six months later the distribution may be approaching end of life, a DDS discovery issue appears when a third robot joins the fleet, and nobody on your side can read the code well enough to fix it.

The root cause is usually not incompetence. It is a mismatch between what was scoped and what was needed. Outsourcing ROS 2 development works well when both sides agree in advance on what “done” means at the level of tests, documentation, and hardware validation. It works badly when “done” means “the video looked good.”

The questions below are ordered roughly by the order you should ask them. The first block filters for basic competence. The later blocks matter more for long-term cost. None of them require you to be a ROS 2 expert yourself – but the answers will tell you quickly whether the person across the table is one.

What should you ask about ROS 2 experience and architecture?

Start here. ROS 1 experience does not transfer automatically. The middleware, build system, launch system, and managed-node lifecycle model all changed. A team that has shipped ROS 1 systems for a decade may still be learning ROS 2 patterns.

These five questions establish whether the partner has genuine ROS 2 depth in their robotics software work:

1. Which ROS 2 distributions have you shipped to production, and which are you recommending for this project? You want to hear a specific distribution tied to a specific support window. ROS 2 uses a mix of long-term support and non-LTS releases; LTS distributions carry multi-year support while non-LTS releases are supported for a much shorter period. Check the current support dates on the official ROS 2 Releases documentation rather than taking a verbal claim at face value. A partner who shrugs at this question has not thought about your maintenance horizon.
2. Which DDS implementations have you deployed, and how do you configure discovery for multi-robot setups? ROS 2 supports multiple RMW implementations (Fast DDS, Cyclone DDS, Connext among them). Each can behave differently under multicast-restricted networks, over Wi-Fi, and at scale. A credible answer mentions specific QoS profiles, discovery server or static-peer configurations, or ROS_DOMAIN_ID segmentation strategies – not just “we use the default.”
3. How do you decide between a lifecycle node, a regular node, and a composable node? This is a quick competence probe. Lifecycle nodes provide controlled startup and shutdown, which can matter for safety-related subsystems. Composable nodes let you load multiple nodes into one process and, when intra-process communication is configured appropriately, can reduce serialization overhead on high-bandwidth topics like camera streams. If the answer is “we always use regular nodes,” expect performance surprises.
4. What is your approach to real-time requirements, and when do you say a task does not belong in ROS 2? ROS 2 can support soft real-time behavior with the right executor and a tuned kernel, but hard real-time motor control often belongs on a microcontroller or another dedicated real-time system. Good partners draw this line explicitly and describe the interface between the two domains.
5. Show us a navigation or perception stack you integrated, and explain one thing you had to replace in the stock configuration. Anyone can run Nav2 from a tutorial. The interesting answer describes a tuned controller, a custom behavior tree node, or a costmap plugin written for a specific environment. Concrete examples over generalities is the standard you should hold here.

How do you verify their testing and CI practices?

Testing is where ROS 2 development services separate into two groups. The first group writes tests because the client asked. The second group writes tests because they cannot ship without them. The difference shows up in your maintenance budget two years later.

Ask these four questions about verification:

6. What is your unit, integration, and system test split, and what is actually covered? ROS 2 ships with testing tooling – ament_cmake test macros, launch_testing for process-level integration tests, and standard Python and C++ test frameworks. You want to know whether node logic is tested in isolation and whether launch files are exercised end to end. Ask for a coverage figure and treat it as directional, not absolute; coverage percentage tells you about habits, not correctness.
7. What runs in CI on every commit, and how long does the pipeline take? A reasonable pipeline builds the workspace, runs linters (ament_lint), runs unit tests, and runs at least a subset of integration tests in a container. If the answer is “we build locally and push,” that is a meaningful signal. Ask whether CI builds against the target architecture – a stack that compiles on x86 but has never been cross-compiled or natively built for ARM64 may surprise you on a Raspberry Pi-based platform.
8. How do you use simulation in the test loop, and where do you stop trusting it? Gazebo, including the simulator formerly called Ignition Gazebo, or Isaac Sim can catch planner regressions and logic errors cheaply. They do not catch wheel slip on wet grass, IMU drift from motor vibration, or a camera that overexposes in direct sunlight. Field robotics in particular punishes teams that treat simulation as a substitute for outdoor testing. A good partner states explicitly which failure classes their simulation covers and which it does not.
9. How do you reproduce a field failure? The expected answer involves ros2 bag recordings, structured logging, and a replay workflow. Ask what they record by default and how much storage that consumes per hour. A team without a bag-based debugging workflow may lack a mature process for diagnosing field failures.

What documentation and handover should you require?

Documentation is the asset you keep after the engagement ends. It is also often dropped when a fixed-price project runs late, which is exactly why it belongs in the contract rather than in a hopeful email.

Three questions cover the handover surface:

10. What documentation artifacts are in scope, and can we see an example from a previous project? At minimum you want: a system architecture description with the node graph and topic list, per-package READMEs, a parameter reference with units and valid ranges, build and deployment instructions reproducible from a clean machine, and a troubleshooting guide. Ask to see a redacted sample. Partners with mature documentation practices should be able to provide one.
11. How will you transfer knowledge to our engineers? Documents alone rarely transfer tacit knowledge. Look for scheduled walkthrough sessions, recorded architecture reviews, and a period where your engineers write code with theirs reviewing. Budget for this explicitly rather than assuming it happens for free.
12. What is the onboarding time for a new engineer on this codebase? Phrase it as: “If we hire a mid-level ROS 2 developer, how long until they can ship a feature?” An honest answer in weeks, with reasoning, is better than a confident “a few days.”

Who owns the code, and what happens after deployment?

This block is the one most often left vague until it is expensive to clarify. Settle it before work starts.

Three questions define ownership and continuity:

13. Who owns the deliverable code, and what pre-existing components are you bringing in? Many partners have internal libraries they reuse across clients. That is normal and often good for you. What is not acceptable is discovering after delivery that a core module is licensed to you under terms you cannot sublicense to your own customers. Ask for a written inventory: which parts are assigned to you or developed specifically for the project, which are licensed, and under what terms. Separately, audit third-party ROS 2 package licenses – the ecosystem mixes Apache 2.0, BSD, and GPL-family licenses, and a GPL dependency in a product you ship as a binary can have consequences depending on how it is used and distributed.
14. What does maintenance look like after go-live, and what is the response path for a field-stopping bug? Define the support window, the escalation contact, and what counts as a bug fix versus a new feature. Also ask who handles ROS 2 distribution upgrades. Migrating a stack across distributions is real work, and it is far cheaper when planned than when forced by an end-of-life date.
15. Do you have the target hardware in-house, and how much of the development happens on it? This may be the single highest-signal question in the list. A partner developing against a simulated differential drive base will miss timing behavior, CAN or serial bus quirks, power budget limits, and thermal throttling. Ask whether they own a unit of your platform, whether they can procure one, and what fraction of integration testing happens on physical hardware. For teams using a documented, off-the-shelf platform such as the Leo Rover, this is straightforward to verify because the hardware is standardized and the ROS 2 packages are public.

Which engagement model fits which type of ROS 2 project?

The 15 questions above assume a partner. The structure of that partnership changes which answers matter most. Three models dominate ROS 2 development services, and each shifts risk differently.

Here is how the common models differ in practice:

• Fixed scope, fixed price. Works when requirements are genuinely stable and the hardware is known – for example, porting an existing ROS 1 stack to ROS 2 on an unchanged robot, or integrating a well-specified sensor. The risk is that robotics requirements are rarely stable. Every change request becomes a negotiation, and documentation is often the first casualty of schedule pressure. If you choose this model, write the testing and documentation deliverables into the scope as named artifacts, not as adjectives.
• Time and materials. Works for exploratory work: a new perception approach, an unproven autonomy behavior, or early-stage prototyping where you expect the specification to move. You carry the schedule risk, so you need real visibility – weekly demos on hardware, access to the repository from day one, and CI results you can read yourself. Without those controls, this model turns into an open-ended burn.
• Embedded team or staff augmentation. Engineers from the partner work inside your process, your repository, and your review workflow. This can facilitate knowledge transfer, because your team has direct access to the work as it happens. It is also the most demanding on your side: you need an internal technical lead who can direct the work. If you do not have that person, this model degrades into expensive time and materials.

A fourth option sits outside these three: buying a platform with an existing, documented ROS 2 stack and contracting only the application layer on top. This narrows the surface area dramatically. Instead of outsourcing drivers, kinematics, and base navigation, you outsource the part that is actually specific to your use case. For many research and industrial inspection projects, that can be the lowest-risk path, because the hardware and base software are already available and publicly documented.

How should you compare proposals once the answers come back?

Score the answers, not the confidence. A partner who says “we have not deployed on ARM64 for this distribution, here is how we would de-risk it” is giving you more usable information than one who says “no problem” to everything.

When you review proposals side by side, look at these signals:

• Specificity. Named distributions, named DDS implementations, named test frameworks. Vagueness at proposal stage becomes vagueness at delivery.
• Artifacts over claims. A sample documentation package, a public repository, a CI configuration file. Evidence-based answers beat narrative.
• Stated limitations. Every real engineering team has scope boundaries. Teams that name theirs tend to be the ones who deliver what they promised.
• Hardware access plan. Written, with dates. “We will get a unit” is not a plan; “we have a unit and integration testing starts in week three” is.
• Maintenance pricing. If the post-deployment number is missing or hand-waved, the total cost of the project is unknown.

One practical tactic: send the 15 questions in writing and ask for written answers. It costs the partner a few hours and requires little from you beyond review time. The quality and precision of the written response gives you concrete evidence of how the partner communicates technical decisions and manages engineering detail.

Frequently asked questions

Do we need all 15 questions for a small integration project?

No. For a short engagement – adding a sensor driver, tuning an existing navigation stack – questions 1, 6, 10, 13, and 15 cover most of the risk. The full list matters when the partner is building a system you will own and maintain for years.

How much ROS 2 knowledge do we need internally to manage an outsourced project?

At least one person who can read the node graph, run the stack, and review a pull request. Without that, you cannot verify any claim the partner makes, and the engagement becomes trust-based. If you do not have that person, the embedded team model or hiring a part-time technical advisor is usually cheaper than the alternative.

Should we require a specific ROS 2 distribution in the contract?

Specify both the target distribution and a minimum support window. Write something like “the delivered stack must target ROS 2 [distribution], with official support through at least [date],” or require agreement on a named supported distribution before implementation begins. A support-window requirement alone does not define the runtime environment, while a distribution name alone may be near end of life by the time the project ships. Verify current support dates in the official ROS 2 documentation.

Is open-source hardware with a published ROS 2 stack actually lower risk?

It reduces a specific class of risk: unknown drivers, undocumented interfaces, and vendor lock-in at the hardware layer. When the base packages are public, your partner can read them before quoting, and your own engineers can audit them afterward. It does not eliminate integration risk for your application-specific code, which is where the 15 questions still apply.

What is a reasonable amount of development time spent on physical hardware?

There is no universal figure, and anyone quoting one precisely is guessing. A practical rule for field robotics projects: every autonomy behavior should be validated on hardware in the target environment before it is marked complete, and bag data from those runs should be part of the deliverable. Simulation-only sign-off often leads to field surprises.

How do we handle the transition if we later want to bring development in-house?

Plan it at contract time, not at the end. Require repository access from day one, documentation as a named deliverable, and a defined handover period with overlap between teams. Question 12 – new engineer onboarding time – is a useful proxy to track, because it reflects how easily the codebase can be understood and extended.

Can the same partner handle both mechanical integration and ROS 2 software?

Some can, many cannot, and there is no inherent advantage to bundling. What matters is a single point of accountability for the integrated system. If you split the work, define explicitly who owns the interface between mechanics, electronics, and software, and who is responsible when a problem crosses that boundary.

Where to go from here

The questions in this checklist exist to make one thing visible: whether a robotics software partner builds systems you can maintain, or demos you can show once. Ask them in writing, compare the answers on specificity rather than tone, and treat testing, documentation, and hardware access as contract line items rather than assumptions.

If your project needs a ROS 2 stack built on hardware that is already documented, Fictionlab’s team works on custom robotics applications built on the Leo Rover and Raph Rover platforms. You can review the scope of that work and start a technical conversation at Fictionlab Custom Robotics.