Short answer: A pilot cell proves that a robot can do the task once, under attention. Production requires that the same cell do the task ten thousand times, under routine. Scaling succeeds when the pilot is run like a data-collection exercise for the rollout — cycle times, failure modes, adjustment history — and fails when the pilot is treated as a demonstration. Design the pilot to production standard from day one, or expect to engineer the cell twice.
What the pilot must measure
A pilot that only reports "it works" has wasted its budget. The rollout team needs numbers: achieved cycle time against target across full shifts, not best runs; first-pass yield and where the failures cluster; every manual intervention, with its cause; and the adjustment history — every tweak an engineer made to fixtures, programs or parameters to keep the cell running. That last record is the one most often missing and the one that matters most, because undocumented tweaks are exactly what the copied cells will not have. Run the pilot across the real variation of production: different part batches, different operators, all shifts, worn tooling as well as new.
Where ramp-ups stall
The bottleneck moves. The pilot cell is rarely the constraint; its neighbours are. Upstream supply at pilot pace is hand-fed and forgiving — at line pace it starves or floods the cell. Downstream inspection, packing or buffering sized for the pilot becomes the queue. Model the whole line's takt before ordering copies.
Attention does not scale. A pilot survives because an engineer walks past it hourly. Ten production cells get a maintenance rota. Every failure mode the pilot revealed needs a designed answer — a sensor, an alarm, a recovery routine, a spare — not a person who happens to notice.
Parts vary more than the pilot saw. A longer run meets the tails of the distribution: castings at the edge of tolerance, packaging that changed supplier, labels in a new position. Cells copied from a short pilot inherit its narrow assumptions.
Standardise the cell, then copy it
Freeze a cell design before replication: one mechanical standard (base, fixture, guarding), one electrical standard, one program template with parameters rather than hard-coded values, and a documentation package that lets a competent integrator rebuild the cell without the original team. Define in advance which points may be adapted per site — floor anchors, infeed height, network details — and which may not. System integrators earn their fee at exactly this stage: turning a working prototype into a repeatable product is their trade, and the integrator section of the directory (81 companies as of 10 November 2026) is where most factories find that help. Our companion guide explains what an integrator actually does across such a rollout.
The documentation package deserves its own paragraph, because it is the asset the whole rollout multiplies. For each cell design it should contain: mechanical and electrical drawings as built, the program template with its parameter sheet, the safety assessment, the acceptance test protocol with the pilot's recorded results, and the spare-parts list with supplier references. If any of these lives only in the pilot team's heads or laptops, the second cell will quietly become a redesign project. Buyers should contract for this package explicitly — integrators produce it routinely when asked, and its absence is discovered, expensively, at cell number three.
People and maintenance scale too
Ten cells need operators trained to a syllabus, not by shadowing the pilot's champion. They need a spare-parts shelf sized for ten cells, a preventive-maintenance calendar, and clear ownership: who may change a program, who approves a parameter change, and how changes propagate to the other nine cells. Configuration drift between supposedly identical cells is the quiet failure mode of every scale-up; treat program versions like engineering drawings, under revision control.
Set the rollback points in advance
Decide, before the rollout starts, what evidence would pause it: yield below a threshold after a defined run-in, a recurring fault without a root cause, a safety observation. Phased rollouts — two cells, prove, then the rest — cost a little time and buy the option to fix the design once instead of ten times. Agree in the contract how repeat cells are priced, what documentation is delivered with each, and who owns the design if you later copy it with a different partner.
Frequently asked questions
How long should a robot pilot run before scaling?
Long enough to meet production's real variation: multiple part batches, all shifts, new and worn tooling. Judge the pilot by the completeness of the data it produced — cycle-time distribution, failure log, adjustment history — not by a calendar period or a single successful week.
What is the most common reason a robot scale-up fails?
The pilot quietly depended on engineering attention that production will not have. Undocumented tweaks, hand-sorted parts and hourly walk-bys made the pilot work; the copies inherit none of them. A pilot run under production-realistic discipline is the main defence.
Should every production cell be identical to the pilot?
The design should be standardised — mechanics, electrics, program template, documentation — with a short, explicit list of points that may be adapted to each site. Identical where it matters, adaptable where the building forces it.
What should the purchase contract say about scaling up?
Price and lead time for repeat cells, the documentation package delivered per cell, spare-parts provisioning, and who owns the cell design if you replicate it with another integrator later. These terms are cheap to agree before the pilot and expensive afterwards.