From pilot to production: the scale paradox in warehouse robotics

Warehouse robotics has moved past the point where a pilot demo can settle the question of whether the technology works. The more interesting question now is what happens when that same system has to survive day-to-day operations across multiple facilities, with different layouts, staffing patterns, package mixes, and exception cases.

That is the tension Christina Gomez-Terry, in a June 1 interview with Robotics & Automation News, puts at the center of the current market. Plus One Robotics has now surpassed 2 billion lifetime picks across its deployed fleet, a milestone that signals experience at scale, but also underlines a more sobering point: throughput numbers are not the same thing as operational readiness.

In the interview, Gomez-Terry’s message is clear enough to matter for technical teams. Pilot success does not automatically translate into scalable deployment. The failure mode is not usually that the robot cannot do the task. It is that production reveals a reliability and maintainability burden that pilots rarely expose. Once systems are running continuously, the cost of hardware wear, software update risk, spare-parts availability, and coordination between teams becomes part of the product whether vendors planned for it or not.

Reliability and maintainability: production reveals the cracks

The interview’s most useful corrective is also its most practical: scale is where maintenance becomes a design problem.

In a pilot, a site can often absorb manual intervention. A field engineer can be nearby. A software patch can be delayed. A part that is not stocked locally can be overnighted. At production scale, those assumptions start to fail. Hardware degrades under continuous use. Components wear unevenly across sites. Update cycles introduce risk because every software change is now a fleet event, not a single-system change. Even minor errors can become operational incidents if they touch enough robots or enough facilities at once.

That is why the interview’s emphasis on spare-parts logistics matters. A scalable robotics program needs more than a maintenance checklist. It needs a distribution strategy for critical components, a policy for what gets stocked locally versus centrally, and an update orchestration model that limits blast radius. In other words, reliability engineering becomes an operational discipline, not just an internal QA concern.

Live feedback loops sit in the same category. If field issues are not routed back into product, software, and hardware decisions quickly, teams end up reacting to the same failure modes repeatedly. The system learns slowly, and the fleet pays the price.

Q&A with Christina Gomez-Terry on scaling warehouse robotics

To understand why scale changes the operating model, the interview is worth reading as a Q&A rather than a product pitch. Gomez-Terry’s core framing is that warehouse robotics is no longer being judged only on whether it can execute a task, but on whether it can do so reliably enough to fit into the rhythms of an industrial operation.

That distinction matters because production exposes hidden dependencies.

A pilot may validate motion planning, grasping, or object recognition under controlled conditions. Production asks different questions: How often do components wear out? What happens when a software revision behaves differently across mixed site configurations? How are failures logged, triaged, and fed back into the roadmap? Which issues are local service problems, and which are product defects?

The interview makes the case that these are not peripheral support questions. They are central to whether a deployment can scale past one or two sites.

Operational engine: cross-team coordination and live feedback

If there is a single operational pattern that separates successful scale-ups from stalled deployments, it is cross-functional coordination.

Robotics programs tend to split naturally into silos: hardware engineering, software engineering, field service, site operations, procurement, and customer success. That division is manageable in a pilot. At fleet scale, it becomes a coordination problem. A hardware issue may require a procurement decision, a field-service response, and a software change. A software update may depend on site readiness, maintenance windows, and operator retraining. If those teams are not working from the same telemetry and escalation process, issues drift from one group to another without being resolved.

The interview’s focus on live feedback loops speaks directly to that failure mode. A feedback loop is not just a channel for bug reports. It is an operational system for deciding which incidents are symptoms of local conditions and which are signs of a broader design flaw. It is also the mechanism by which product teams learn how robots behave under real warehouse pressure rather than in demo conditions.

That distinction has technical consequences. Without structured feedback from production sites, software teams can optimize for the wrong edge cases, hardware teams can miss wear patterns until they become failures, and ops teams can end up compensating for product gaps with manual workarounds. Scale then becomes brittle: it appears successful until the hidden labor of coordination finally breaks.

Roadmap and market positioning: reliability as a product feature

The 2 billion lifetime picks milestone is notable not because it is a marketing headline, but because it points to a larger market reality: customers are buying ecosystems, not isolated robots.

Once fleets grow, reliability becomes part of the product surface area. Roadmaps have to account for maintenance architecture, serviceability, update control, and the mechanics of operating a distributed system across sites. API standards and integration discipline matter because they determine how easily operators can connect robotics data with warehouse systems, service tools, and exception handling workflows.

The same is true for supplier strategy. A fleet that depends on slow-moving or opaque parts logistics is a fleet with a built-in scaling limit. Resilient ecosystems require redundant supplier relationships where possible, clear ownership of serviceable components, and enough operational visibility to predict when equipment will need replacement rather than waiting for a failure.

That is the strategic implication in Gomez-Terry’s interview: the market will increasingly reward vendors that treat reliability not as a support afterthought, but as a core product capability.

What to watch next: signals for 2H 2026 and beyond

For operators planning the next wave of deployments, the practical lesson is to measure readiness for scale in operational terms, not just technical ones.

A few signals matter most:

• Whether the vendor can describe a repeatable maintenance model for wear parts and field repairs.
• Whether software updates are staged, reversible, and observable across the fleet.
• Whether site issues are feeding back into product decisions quickly enough to change design priorities.
• Whether internal teams share the same incident taxonomy, escalation path, and ownership model.
• Whether parts logistics and service coverage are designed for multi-site operations, not just single-site support.

For vendors, the next phase of competition is likely to hinge on reliability metrics that are visible to customers and useful to operators. For buyers, the key question is less “does the robot work?” and more “does the operating model around it scale without adding fragility?”

That is the shift Christina Gomez-Terry’s interview captures well. Warehouse robotics has proven it can perform. The harder engineering problem is making that performance sustainable once the fleet, the site count, and the operational complexity all start rising at the same time.