"We'll just build our own data pipeline" is a sentence usually said by someone who has scoped the recorder and not the other seven systems it depends on. Robot data infrastructure is not one thing — it is transport, orchestration, synchronized recording, storage, conversion, QA, versioning, and access control, each with its own engineering cost and its own way of quietly breaking six months later.
The short version
| Build | Buy | |
|---|---|---|
| Time to first dataset | Months, after infrastructure is functional | Days to weeks, using existing tooling (illustrative) |
| Ongoing maintenance | Yours — format drift, scaling, on-call | Vendor's, if the contract covers it |
| Fit to unusual constraints | Exact, since you control every layer | Bounded by what the vendor supports |
| Engineering opportunity cost | High — team builds plumbing, not product | Low — team focuses on the policy and product |
| Lock-in risk | None by construction | Only if the vendor uses closed formats |
| Cost shape | Large upfront, ongoing maintenance burden | Recurring, scales with usage (illustrative) |
| Right when... | Pipeline is your differentiator or team already exists | Data is the goal, not the pipeline |
What "the infrastructure" actually is
The phrase hides eight separate systems, and most build-vs-buy conversations only ever price out the first one or two.
- Low-latency transport. Getting camera, joint, and force data from robot to operator and commands back, inside a latency budget tight enough for contact-rich teleoperation — this alone is a real-time networking problem, not a REST API.
- Session orchestration. Starting and stopping recordings, attaching metadata, marking episode boundaries and success/failure — the layer that turns a stream of bytes into something with structure.
- Time-synced recording. Multiple cameras, joint encoders, and sometimes force sensors, all sampled at different rates, all needing to land on one clock. Get this wrong and every downstream consumer inherits silently misaligned data — see time-syncing sensors to one clock for what actually goes wrong when this is skipped.
- Storage and lifecycle. Hot storage for active collection, archival for completed datasets, a deletion or retention policy, and the cost curve of multi-camera video at scale — none of which is "just an S3 bucket" once you have real retention and access requirements.
- Format conversion. Raw recordings rarely land in the format your training stack wants. Converting into LeRobot, RLDS, or another training format is its own ongoing maintenance surface, especially as those formats themselves evolve.
- QA tooling. Catching corrupted episodes, dropped frames, and outlier sessions before they reach a training run — see dataset quality assurance for what a real QA pass checks for.
- Dataset versioning. Being able to say precisely which episodes went into a given training run, and reproduce that set later, is a distinct system from storage — versioning without it means "we trained on roughly this data" is the best answer you can give.
- Access control. Who can read, export, or delete data — increasingly a hard requirement once a dataset includes anything sensitive, and a system in its own right once you have more than a handful of collaborators.
What each piece really costs
None of these eight systems is a weekend project once it has to survive contact with a real collection program — a growing number of operators, task types, and downstream training consumers. The honest cost is not just the initial build; it is the ongoing maintenance nobody budgets for: message schemas drift as sensors change, storage costs grow with every week of collection, format converters need updates when the training team adopts a new stack, and QA tooling needs new checks every time a new task type reveals a new failure mode. A pipeline that was a few engineer-quarters to stand up can easily cost a fraction of an engineer's ongoing time to keep working — a cost that shows up on no one's original estimate because it was never on the roadmap, just accumulated as "someone has to fix the sync bug."
When building is right
The pipeline is your actual differentiator. If your product is the data infrastructure itself, or your competitive edge depends on collection or processing techniques nobody else has, building in-house is not overhead — it is the work.
Your constraints are genuinely unusual. A sensor suite, latency budget, or deployment environment far outside what any vendor supports means a bought solution would require so much customization that you are effectively building anyway, just on someone else's foundation.
You already have the team. If the engineers who would build this already exist and are not needed elsewhere, the opportunity cost that dominates the build-vs-buy tradeoff for most teams is much smaller for you specifically.
When buying is right
Data is the goal, not the pipeline. If your team's job is training policies, not maintaining recording infrastructure, every quarter spent building session orchestration is a quarter not spent on the model. This is the most common case, and the one build-vs-buy conversations most often get wrong by treating infrastructure as a one-time cost rather than the ongoing maintenance burden described above.
You need results this quarter. Standing up all eight pieces to a production-reliable standard takes real time. If the constraint is a training run or a demo deadline, buying existing, working infrastructure is the only path that fits the timeline.
You do not yet know your infrastructure requirements. Early in a program, before you know your actual task mix, sensor needs, and scale, building bespoke infrastructure risks optimizing for requirements that turn out to be wrong. Buying lets you learn what you actually need before committing engineering time to a permanent system.
- The pipeline itself is your product or competitive edge.
- Your constraints are outside what any vendor's pipeline supports.
- You already have the team and they are not needed elsewhere.
- You are running at a scale where the ongoing maintenance cost is small relative to the value it protects.
- Your job is training policies and shipping a product, not maintaining a pipeline.
- You need a working dataset in weeks, not after a multi-quarter build.
- You do not yet know your long-term infrastructure requirements.
- The engineering opportunity cost of building plumbing is higher than the cost of buying it.
Why open formats make this decision low-risk either way
The reason build-vs-buy does not have to be a permanent, high-stakes bet is open, documented formats. If a vendor exports your data in MCAP, LeRobot, RLDS, or another open format rather than something proprietary, the buy decision stays reversible: you can bring collection in-house later, switch vendors, or mix and match pieces of the pipeline, because nothing about your dataset depends on staying with the vendor that produced it. Lock-in risk in this space almost never comes from the buy decision itself — it comes from a closed format that makes leaving expensive regardless of who built the pipeline. Ask any vendor directly what format your exported data lands in and whether the schema is documented publicly; that answer matters more to your future flexibility than almost anything else in the contract.
The recommendation
Scope all eight pieces of the pipeline, not just the recorder, before comparing build cost to a buy price — most build-vs-buy comparisons are unfair because they price a partial build against a complete bought system. Build when the pipeline is your differentiator, your constraints are genuinely unusual, or you already have the team with room to spare. Buy when your team's value is in the policy and the product, not the plumbing, and you need working infrastructure sooner than a multi-quarter internal build could deliver it. Whichever way you go, make open formats a non-negotiable requirement — it is what turns build-vs-buy from a one-way door into a decision you can revisit as your program's actual needs become clear.