Build vs Buy: When a Custom Mobile Robot Makes Sense and When to Start From a Platform

TL;DR: The build vs buy mobile robot decision rarely comes down to hardware cost alone. It comes down to five variables: budget structure, time to first field test, technical risk, long-term maintenance, and how many units you expect to deploy. If your research question lives in software – navigation, perception, multi-robot coordination, autonomy stacks – starting from an existing ROS 2 platform can remove months of mechanical and electrical work that does not advance your thesis. If your differentiation lives in the chassis itself – unusual payload geometry, extreme environmental sealing, a drivetrain no suitable commercial platform offers – a custom build may be the only path that gets you there. Most projects land in a third category: a proven platform with targeted modifications. This guide walks through the decision matrix and three viable paths so you can place your own project.

Why does the build vs buy mobile robot question keep coming back?

Nearly every mobile robotics project starts with the same stall. A team has a clear research goal or product concept, a payload sketch, and a rough sense of the environment. Then someone asks: do we design the robot, or do we buy one and build on top of it?

The question keeps returning because both answers look reasonable on a whiteboard. Designing a UGV from scratch feels like total control. Buying a platform feels like speed. Both framings are incomplete.

What actually separates the two paths is where you choose to spend your engineering hours. A mobile robot is not one system. It is a drivetrain, a power architecture, a compute stack, a sensor interface layer, a chassis, an enclosure, a thermal design, a communication link, and the software that ties all of it together. Every project needs all of these. The build vs buy mobile robot decision is really a decision about which of those layers you want to own and which you are willing to inherit.

Fictionlab’s team sees this pattern across research labs, integrators, and product teams. The groups that move fastest are usually not the ones with the biggest budgets. They are the ones that identified early which layers were genuinely novel to their work and which were commodity infrastructure dressed up as a design challenge.

What should your decision matrix actually measure?

Before comparing specific platforms or quoting a mechanical design firm, it helps to score your project against five dimensions. These are the variables that most reliably predict whether a build vs buy mobile robot decision will hold up twelve months in.

• Cost structure, not just cost. A custom build concentrates spending up front in design, prototyping, and tooling. A platform shifts spending toward unit price and integration. Neither is inherently cheaper. What differs is when the money leaves and how much of it is recoverable if requirements change.
• Time to first meaningful test. How long until you can run your actual algorithm on actual terrain? This is the single most underestimated variable. A custom chassis that is 80 percent finished produces zero data.
• Technical risk concentration. Where is the uncertainty in your project? If the hard part is a SLAM approach in GPS-denied environments, adding chassis risk on top of algorithm risk compounds your failure modes.
• Maintenance and spares. Who repairs the robot when a motor controller dies during a field campaign? Custom builds mean you are the supply chain. Commercial platforms may come with documented part numbers and vendor support, but spare-part availability should be confirmed for the specific model.
• Scale. One robot, five robots, or fifty? Custom designs amortize engineering cost across units. At single-digit quantities, that amortization rarely closes the gap. At higher volumes with stable requirements, it can.

Score each dimension honestly. A project that is cost-sensitive, time-constrained, software-focused, and single-unit points clearly toward a platform. A project with stable high-volume requirements and genuinely unusual physical constraints points toward custom. Mixed scores point toward the middle path.

How technical risk should weight the decision

Risk deserves more weight than most teams give it. In a custom build, you carry mechanical risk, electrical risk, thermal risk, software integration risk, and your actual research risk simultaneously. Each one can delay the others.

Consider a field robotics team studying autonomous navigation in forested terrain. Their novel contribution is a perception pipeline. If they also design a suspension, they now have to debug whether a failed navigation run was caused by their planner, their odometry calibration, or a drivetrain that loses traction in a way they have not characterized yet. Starting from a platform with documented kinematics and published specifications can remove an entire class of ambiguity from their experiments.

When does starting from a ready platform make sense?

The first path is the simplest: take a commercially available ROS 2 robot, bolt on your sensors, and start collecting data. This works when your value sits in software or in a payload you can mount without redesigning the vehicle.

The Leo Rover is built for this case. It is an outdoor-capable four-wheel-drive UGV with ROS 2 support, an onboard computer, and a mechanical interface designed for third-party payloads. The official documentation publishes the drivetrain configuration, power information, and software architecture, which means you can plan your integration before the robot arrives rather than reverse-engineering it after.

A ready platform is the right call when several of the following hold true for your project:

• Your research or product contribution is in the autonomy stack, not the vehicle.
• You need to demonstrate something working within a single academic term, grant period, or sprint cycle.
• Your payload fits within the platform’s published mass and volume envelope.
• You want reproducibility – other labs running the same hardware can validate your results.
• Your team is strong in software and thin in mechanical or electrical engineering.
• You expect requirements to evolve, and you want to avoid committing to a frozen mechanical design early.

The constraint of this path is honest and worth stating: you accept the platform’s envelope. Its ground clearance, its power budget, its mounting geometry. If your application genuinely exceeds those limits, no amount of clever integration will fix it, and you should move to path two or three.

What “open source” actually buys you here

Open-source hardware can change the calculus of the build vs buy mobile robot decision in a specific way. When CAD files, firmware, and electrical schematics are published under licences that permit modification, buying a platform does not necessarily lock you out of changing it. You can read the design, understand why a decision was made, and modify it if the applicable licence allows.

That is materially different from a closed commercial robot where the integration surface may be limited to a documented API. With openly published design files and suitable licences, “buy” and “build” stop being binary. You are buying a known-good starting geometry while retaining the option to diverge from it.

When does a platform plus modifications become the right path?

This middle path covers most serious deployments, and it is the one teams most often arrive at after trying one of the extremes.

The pattern is straightforward. Start from a proven base, keep the drivetrain, power system, and core software stack, and change the specific layers that do not fit. That might mean a taller chassis for ground clearance, a custom sensor mast, a different battery configuration for extended runtime, or a reworked enclosure for an unusual environmental requirement.

The Raph Rover exists partly because of this pattern. Larger payload capacity and a heavier-duty drivetrain open applications that smaller platforms cannot serve, while the ROS 2 software foundation and documented interfaces stay consistent. Teams moving from early prototyping to field deployment often need exactly that – more physical capability without rewriting their entire stack.

The modification path tends to fit when your requirements look like this:

1. Roughly 70 to 90 percent of a platform’s specification already matches your needs, and the gap is concentrated in one or two subsystems.
2. You need a specific environmental rating, payload interface, or sensor arrangement that no stock configuration provides.
3. You plan to deploy a small fleet where consistency between units matters more than per-unit optimization.
4. You have in-house engineering capacity for the modified subsystem but not for a full vehicle program.
5. You want vendor support for the base platform while retaining ownership of your differentiating layer.

The main thing to watch on this path is modification creep. Each change is individually reasonable. Collectively they can turn into a de facto custom build with none of the planning a real custom program would have had. Set a boundary early: if you are modifying more than two major subsystems, reconsider whether path three is more honest.

When is a full custom mobile robot the only answer?

Full custom development is the right choice less often than teams assume, but when it is right, nothing else works. The clearest signal is that your physical requirements are the innovation, not a constraint around it.

Legitimate reasons to build from scratch include genuinely unusual locomotion – such as specialized tracked systems, articulated bodies, or multi-segment vehicles for which no suitable platform is available. They include extreme environmental envelopes such as high-temperature industrial inspection or deep submersion. They include payload geometries that dictate the entire vehicle architecture rather than mounting onto it. And they include volume production where unit cost optimization over thousands of units justifies the engineering investment.

Custom development is also appropriate when regulatory or certification requirements dictate a design path. If your robot must meet a specific functional safety standard, retrofitting that onto a platform designed for research use can be harder than designing for it from the start.

The realistic trade is this: a custom program gives you a design tailored to your specification and requires you to specify everything. Every connector, every thermal path, every firmware edge case. Teams that succeed at this usually have mechanical, electrical, and embedded software capability in-house, or they partner with a group that does. Fictionlab runs custom robotics projects precisely for teams in this position – where the requirements are real, the platform gap is genuine, and the project needs engineering depth rather than a catalog.

How to avoid the worst version of custom

The failure mode worth naming: building custom because the platform options were never seriously evaluated. This happens when a team scopes requirements from an idealized specification instead of from what the application actually needs.

A useful discipline is to write down your hard constraints – the ones that would make a robot unusable if violated – separately from your preferences. Then check the published specifications of two or three platforms against the hard list only. Teams frequently discover that what felt like a blocking requirement was a preference, and that a platform plus one modification covers it.

How do the three paths compare across the matrix?

Mapping all three options against the five decision dimensions makes the trade-offs easier to see at a glance.

• Cost structure. Ready platform: predictable, mostly unit price. Platform plus modifications: unit price plus bounded engineering. Full custom: front-loaded engineering, higher variance.
• Time to first test. Ready platform: fastest, limited by shipping and integration. Platform plus modifications: moderate, gated by the modified subsystem. Full custom: slowest, gated by the full design cycle.
• Technical risk. Ready platform: generally lowest, with risk focused on integration and your own software. Platform plus modifications: moderate, concentrated in what you changed. Full custom: highest, distributed across every layer.
• Maintenance. Ready platform: typically supported through vendor documentation and available spares. Platform plus modifications: split responsibility. Full custom: entirely yours, including spare inventory.
• Scale. Ready platform: often suitable for one to ten units. Platform plus modifications: often suitable for small fleets. Full custom: justified when volume amortizes the engineering.

One pattern worth noting for research teams: the build vs buy mobile robot decision is not permanent. Many groups begin on a stock platform to validate their approach, then move to a modified configuration once they understand what the application actually demands, and reach custom development only if the product requires it. Each stage produces data that makes the next decision better informed. Starting with full custom can skip part of that learning.

Frequently asked questions

Does starting from a platform limit what research I can publish?

Not if the platform’s specifications and interfaces are documented. Published hardware specifications make your experimental setup more reproducible, which can strengthen the work. Many navigation, SLAM, and multi-robot coordination papers use commercially available bases so other groups can more readily replicate the results. What matters for publication is the novelty of your contribution, not whether you machined the chassis yourself.

How do I know if my payload fits a given platform?

Check three published figures against your payload: mass capacity, available mounting volume, and the power budget on the auxiliary rails. Then add margin. Sensor payloads tend to grow during a project as teams add cameras, IMUs, or compute. If your current payload uses more than roughly 70 percent of a platform’s rated capacity, plan for a modification path rather than a stock configuration.

Is a custom build cheaper at higher volumes?

It can be, but the breakeven depends heavily on how stable your requirements are. Engineering cost amortizes across units only if the design stays frozen. If requirements shift mid-program, you repeat portions of the engineering spend without the volume to absorb it. Volume helps the case for custom; requirement stability is what makes it work.

What happens to my software if I switch platforms later?

If both platforms run ROS 2 and expose standard interfaces – odometry, transforms, velocity commands, sensor topics – most of your autonomy stack can carry over. What typically needs rework is anything coupled to specific hardware drivers, URDF geometry, or calibration parameters. Keeping your application code separated from hardware abstraction layers from day one makes this migration substantially less painful.

Can I modify an open-source platform without voiding support?

That depends on the vendor, the applicable licence, and the specific modification. Open-source hardware can mean you have access to design files and permission to change them, but the exact rights depend on the licence. Whether the vendor continues to support a modified unit is a separate commercial question worth clarifying before you start cutting. Modifications to payload mounting and sensor integration are usually straightforward; changes to the drivetrain or power architecture warrant a conversation first.

How much mechanical engineering capacity does a custom build actually require?

More than most software-focused teams estimate. A field-ready UGV needs mechanical design, electrical design, embedded firmware, thermal analysis, manufacturing coordination, and testing across all of it. Teams without that breadth in-house typically partner with an engineering group rather than hiring across every discipline for a single program.

When should I revisit a build vs buy mobile robot decision I already made?

Revisit it when your application requirements change materially, when you move from prototyping to deployment, or when you find yourself spending more engineering time on the vehicle than on your actual contribution. That last signal is often particularly useful. If your team’s weekly standup is dominated by chassis and power problems rather than the problem you set out to solve, the current path may be costing more than it returns.

Where to go from here

If your project sits clearly in the platform category, the fastest next step is checking published specifications against your hard constraints and ordering a unit. If it sits in the modification or full custom category, the next step is a technical conversation about what the gap actually is.

Fictionlab’s engineering team works with research groups, integrators, and product teams on exactly this question – evaluating whether a modified platform closes the gap or whether a ground-up design is warranted. Talk to Fictionlab about custom robotics and bring your requirements, constraints, and timeline to the discussion.