Build vs Buy: When to Outsource Physical AI Training Data Collection

Author: Praveen Kumar Co-Founder, FutureBeeAI · Reviewer: Jesal Thakkar Founder, FutureBeeAI
Last updated: 01/10/26

Most build-versus-buy analyses for robot training data compare hourly rates. That's the wrong comparison, and the numbers being compared aren't audited by anyone.

Whether you build or buy physical AI training data comes down to one variable: the number of distinct physical environments your policy has to work in. Below roughly a dozen, building in-house is faster and cheaper than any vendor can quote you. Above thirty, the constraint stops being money and becomes logistics.

This piece is published by a company that sells the buy side. The evidence below concedes real ground to building, because the evidence backs it up.

Should You Build or Buy Physical AI Training Data?

Build if your task is narrow, your environment count is low, and you already own the robot. A small team can collect a usable dataset for one task in a controlled setting in a matter of days, and outsourcing that is pure overhead.

Buy when you need coverage across many distinct environments, when the robot doesn't exist yet, or when your deployment spans geographies your team can't physically reach. Those are logistics problems, and throwing internal headcount at them doesn't solve them.

The threshold between the two is measurable, and the rest of this piece is how to measure it. It's worth saying plainly that the middle ground is real: plenty of programs should be doing both at once, for different parts of the same problem, and the sections below cover when.

Why the Cost Question Is the Wrong One

Every vendor conversation starts at cost per hour or cost per demonstration, because that's a number a vendor can quote and a buyer can compare.

It's also the number least connected to whether the resulting policy actually works. A dataset can be cheap per hour and worthless, if every hour was recorded in the same room against the same background under the same lighting. It can be expensive per hour and transformative, if the hours are spread across thirty buildings.

Cost per hour measures the input. What determines the outcome is the shape of the coverage, and the two are only loosely related. Anchoring the decision on price means optimizing the variable that matters least, and doing it early, before anyone has established what coverage the deployment actually needs.

What It Took to Build DROID

DROID is one of the most widely used open robot manipulation datasets, and its paper discloses exactly what building it required.

Seventy-six thousand trajectories. Three hundred and fifty hours of interaction. Five hundred and sixty-four scenes across 52 buildings. Fifty data collectors, 18 robots, 13 institutions spread across North America, Asia, and Europe, running for twelve months.

The authors are direct about why it was hard, noting that collecting manipulation data in diverse environments "poses logistical and safety challenges when moving robots outside of controlled lab environments."

Read that as a build estimate. Fifty people and thirteen institutions over a year, for 350 hours. That's what breadth costs when a well-funded academic consortium with donated lab access does it, which is a cheaper starting position than most companies have.

What It Took to Reach 90% on Two Tasks

Now the other number, from the same body of research.

The team studying data scaling laws in robot manipulation reported reaching roughly 90% success on two tasks using four collectors working a single afternoon.

Four people. One afternoon. Against fifty people and twelve months.

Both numbers are real, both are peer-reviewed, and they describe the same activity. The difference isn't budget, seniority, or tooling. It's what the policy was being asked to do: two tasks in known conditions, versus generalization across 52 buildings.

Any build-versus-buy argument that doesn't explain this gap is selling you something. The gap is also why internal estimates and vendor quotes so rarely reconcile: one side is usually pricing the afternoon and the other is pricing the twelve months, and neither says which.

The Variable That Decides It

Here's what separates those two numbers.

The data scaling laws research found that generalization follows roughly a power-law relationship with the number of distinct environments and objects, and that "increasing the diversity of environments and objects is far more effective than increasing the absolute number of demonstrations per environment or object." It also found a ceiling: past a threshold, additional demonstrations in the same environment contribute almost nothing.

Their concrete configuration was 32 environments, one unique object each, 50 demonstrations per environment, producing a policy that generalized at around 90% success.

So the decision variable is environment count, not hours and not spend. And environment count is the one input a single-site team can't buy more of by hiring.

Why Nobody Quotes You a Real Number

Ask four sources what a teleoperation hour costs, and you'll get four incompatible answers.

Published vendor figures for usable episodes per operator-hour range from one to sixty, depending on who's talking, a spread that traces back to the gig-economy labor market behind teleoperation. The only non-vendor estimate we found, from a think tank analysis, puts it at fewer than 200 demonstrations per worker per day, roughly 25 an hour, which sits at the pessimistic end of every vendor claim. 

More telling: no dataset paper discloses a dollar cost. Not DROID, not RT-1, not Open X-Embodiment, not BridgeData, not Ego4D. Every per-hour figure circulating in this market traces back to a vendor blog or a venture capital estimate. None of it is audited, and none of it is peer-reviewed.

Treat any quoted rate, including one from us, as a negotiating position rather than a measurement.

The Comparison That Is Worth Making

Compare on constraint, not on price. The table below drops cost per hour entirely, because it's the axis that makes two genuinely different tools look like competing quotes for the same job.

Read the first row first. Everything else follows from where your program sits on it, and a team that hasn't counted its environments can't use the rest of the table.

Two rows deserve a note. Speed to first usable data assumes the robot already exists on the build side, which is the assumption that most often turns out to be false. And cost behavior is the row that misleads: in-house looks cheaper on the margin forever, which is true and irrelevant if the marginal collection is happening in an environment you already covered.

The table has no winner column, and that's the point. These are different tools, and the question of which is "better" has no answer without the environment count.

When Building Is Genuinely Right

Four cases, and they're more common than vendors admit.

Your task is narrow and lives in one controlled setting. The robot is already on your floor and idle between experiments. You're iterating fast on task definition, where a same-day collection loop beats a two-week vendor cycle every time. Or the data is commercially sensitive enough that the review overhead of getting it offsite exceeds the collection cost.

In those cases, a vendor adds a brief, a contract, and a delay, in exchange for capacity you didn't need. The honest advice is to buy a teleoperation rig and get on with it.

The failure mode to watch is treating a successful narrow build as evidence that the in-house approach scales. It's evidence the task was narrow.

When Buying Is Genuinely Right

Three cases, and the first is the one teams underestimate.

You need environmental breadth. Thirty distinct buildings isn't a hiring problem, it's a logistics and access problem, and DROID needed thirteen institutions across three continents to reach 52. Internal headcount doesn't produce buildings which is the gap our data collection services exist to close. 

The robot doesn't exist yet. Teleoperation requires hardware in the loop, but egocentric and handheld capture doesn't, which is how Ego4D reached 3,670 hours using 931 camera wearers and no robots at all.

Or your deployment spans geographies, languages, and operator populations your team can't reach. That constraint is about who and where, and it doesn't yield a budget applied locally. Hiring three more operators in the same city adds hours, not coverage.

The two answers aren't exclusive, and the strongest programs run both.

Build for depth... Buy for breadth . Keep a small in-house rig for the tasks you're still defining, where the iteration loop matters more than coverage and the marginal cost of another fifty demonstrations is nearly zero.

Buy for breadth. Commission the environment coverage you can't physically reach, once the task definition has stopped moving and you know what conditions to specify.

Teams that pick one and commit tend to fail in a predictable direction. Pure in-house builds a policy that works beautifully in one room. Pure outsourced spends heavily collecting breadth for a task specification that's still changing underneath it, and pays twice when it settles.

The sequencing matters more than the split. Define the task in-house, then buy coverage for it.

What You Cannot Outsource Either Way

One thing stays yours regardless of which side you land on: knowing what conditions to specify.

Every randomization range, every environment on the list, every operator profile is a claim about where the system will be deployed. A vendor can execute that claim at scale across places you can't reach. A vendor can't originate it, because they haven't seen your deployment.

This is the same problem that produces biased and unrepresentative physical AI datasets, and it doesn't care who's holding the camera.

In practice, this means the specification work happens before the build-or-buy decision, not after it. A team that can't list its deployment environments can't brief a vendor, and can't direct its own collectors either, so the choice between them is premature.

In FutureBeeAI's collection work, the build-versus-buy conversation almost never arrives as a cost question. It arrives as a coverage question wearing a cost question's clothes, usually after an in-house pilot succeeded in one environment and then failed at the second site.

How to Test Any Number You Are Given

Four questions that expose whether a quote is measurement or marketing, ours included.

How many distinct physical environments does this cover, and are they yours or generic? What's the QA rejection rate, and is the quoted rate before or after rejects? What's the yield per operator-hour, and is it measured on this task or borrowed from another? And what happens to the price when the task definition changes in week three?

A vendor who answers all four with specifics is measuring. One who answers on price per hour alone is quoting a number nobody audits, which describes most of this market.

Run the same four questions on your own internal estimate. In-house numbers are usually built from a pilot in the easiest available environment, which makes them optimistic in exactly the direction that matters.

The Question to Take Into the Meeting

Stop asking what robot data costs. Start by counting the environments your deployed system has to work in, because that number decides the answer before any quote does.

Under a dozen, build, and be skeptical of anyone selling you otherwise. Past thirty, the constraint is access rather than money, and no amount of internal hiring produces buildings you don't have. In between, run both and let the task definition tell you when it's stopped moving.

If you're working out where your program falls, talk to the FutureBeeAI team about mapping environment coverage before anyone quotes you an hourly rate. That conversation is more useful than a price, and it occasionally ends with us telling you to build it yourself.

Frequently Asked Questions

Q. Can I collect demonstration data without owning the robot?

A. Yes, and it's the standard route when hardware doesn't exist yet. Egocentric and handheld capture record human demonstrations with wearable cameras or instrumented grippers, needing no robot and no fixed workspace. Ego4D assembled 3,670 hours this way from 931 camera wearers. The tradeoff is that you get no proprioception and no action labels on your embodiment, so this data pre-trains general competence rather than producing a deployable policy.

Q. How many demonstrations do I need per environment?

A. Fewer than most plans assume, and the returns stop early. Published scaling work found policies generalizing at roughly 90% success from 50 demonstrations in each of 32 environments, and that past a threshold, extra demonstrations in an environment already covered contribute almost nothing. The practical implication is to stop collecting in a covered environment and move the rig, rather than deepening a set that's already saturated.

Q. Is simulation a cheaper substitute for either option?

A. It changes the ratio rather than removing the need. Simulation multiplies coverage from a given set of real demonstrations, particularly across visual and spatial variation, but every randomization range encodes an assumption about real deployment conditions that has to come from observing them. Teams treating simulation as a replacement typically discover the gap at the first unfamiliar site, which is the most expensive place to discover it.

Q. What should an in-house teleoperation rig cost to stand up?

A. Published academic systems give the honest floor. The ALOHA bimanual teleoperation setup was documented at under $20,000 using off-the-shelf arms and printed components, and its mobile version at $32,000 including onboard power and compute. A single-arm research station has been documented at roughly $4,000. Industrial collaborative arms run considerably higher, commonly $30,000 to $85,000 before the surrounding cell.

Q. Why do vendor quotes for the same work differ so widely?

A. Because there's no audited benchmark to anchor them. Published claims for usable episodes per operator-hour span from one to sixty across vendors, and no peer-reviewed dataset paper discloses a dollar cost at all. Quotes also silently differ on what counts: whether the rate is before or after QA rejection, whether setup and operator ramp are included, and whether the environments are yours or generic.