The number on the PO for a robot integration project is usually a labor estimate, sometimes a software license, occasionally a hardware cost for an additional gateway or industrial PC. It is almost never the full cost. The full cost shows up six months later as a series of smaller charges that nobody budgeted for because nobody was tracking them against the original project.
I have commissioned enough cells to have a sense of how the math actually works. This is an attempt to write it out clearly, because the mismatch between what automation projects appear to cost and what they actually cost is one of the main reasons plant managers are skeptical about adding automation capacity.
The Initial Build: What You See on the PO
A mid-complexity workcell integration, say a FANUC robot arm, a Siemens PLC, a Modbus-connected conveyor, and some sensor I/O, requires from one to three weeks of an integration engineer's time for the initial wiring, configuration, and commissioning. At typical US automation engineer billing rates, that is $15,000 to $60,000 in labor, depending on the cell and the engineer's seniority. Add in any gateway hardware, integration software licenses, and travel if the engineer is not local, and a well-documented initial build might land at $40,000 to $80,000 fully loaded.
That number looks manageable for a production cell with a multi-year lifespan. The problem is what comes after.
Vendor Coordination Time: The Hidden Overhead
Custom one-off integrations depend on knowledge that lives in vendor-specific documentation, vendor-specific support forums, and sometimes vendor-specific support contracts. When something breaks or needs to change, you are often on the phone with two different vendor support teams who each know their own product and have limited interest in helping you debug the interaction between their product and someone else's product.
In cells we have worked with, the ongoing vendor coordination overhead for a two-vendor cell typically runs 4 to 8 hours per month. That is not emergency response; that is routine maintenance: firmware update compatibility checks, alarm code lookups, changes needed when a peripheral device gets swapped out. At loaded labor rates, that is $800 to $2,000 per month in coordination overhead that never appeared in the project budget.
For a three-vendor cell, the number does not double; it tends to triple, because the interaction surface expands and some issues require coordinating responses from multiple vendors simultaneously. We have seen cells where vendor coordination overhead was running 15 to 20 hours per month because the integration was fragile and required constant care.
The Maintenance Debt Accumulation
The more insidious cost is maintenance debt. A one-off integration typically involves custom scripts, one-off PLC logic additions, and configuration assumptions that made sense at commissioning but become constraints later. Updating the cell becomes progressively harder because changes need to be traced through a mix of bespoke code, undocumented register assignments, and tribal knowledge that may have left with the original engineer.
A typical pattern: the cell runs fine for the first six months. Then a firmware update changes the behavior of the FANUC interface. The integration engineer who originally wrote the robot interface logic is not available. The engineer who responds to the ticket spends a day reverse-engineering the original implementation before they can even diagnose the issue. The fix takes another half day. Total cost for a problem that would have been trivial with good documentation: $2,500 to $5,000. This happens multiple times per year in cells with heavy customization.
Over three years, the maintenance overhead on a single one-off integration routinely exceeds the initial build cost. We have seen cases where it approaches twice the initial build cost. The project sponsor who approved the initial $60,000 integration never saw the $40,000 in subsequent maintenance charges because they were distributed across dozens of work orders in the maintenance system, not attributed to the integration project.
The Real Cost of Change
The most expensive cost category for one-off integrations is change. Manufacturing cells change. Products change. The plant adds a new robot arm. A conveyor gets replaced. A new MES system comes in and needs different data formats. Each change in a one-off integration is a new custom project.
In the worst-case cell I have been involved with, adding a second robot arm to an existing one-off integration took eleven weeks and cost more than the original integration, because the original architecture had not left any clean extension points. Every new vendor connection had been grafted onto the previous one in the sequence it had been added, and the state machine was by that point too intertwined to modify cleanly without a full rewrite.
We are not saying one-off integrations are always wrong. For a cell with a stable process, a single vendor, and no planned changes over a five-year horizon, a custom integration can be perfectly reasonable. The math works differently in that case.
What we are saying is that the cost case for a shared integration layer rather than a series of one-off builds depends almost entirely on the change rate and the number of vendors involved. If either of those is high, the one-off approach will produce escalating hidden costs over the life of the cell that are difficult to trace back to the integration architecture but are clearly visible in aggregate maintenance spending.
How We Think About This in Sancho
When we designed Sancho's connector architecture, the explicit goal was to make the maintenance cost model predictable. A connector that works for a FANUC M-20iD works for a FANUC LR-Mate with the same configuration model; you do not write new integration code for each robot. When a vendor updates firmware and something in the interface changes, we patch the connector and everyone on that connector type benefits simultaneously rather than each plant engineering team discovering the issue independently.
This does not eliminate maintenance. There is still firmware testing, still configuration updates when a cell changes, still occasional connector bugs. But it concentrates the maintenance work in one place rather than distributing it across every plant that runs the same vendor's hardware. For plants with two or more robot vendors, the savings tend to be clearest in the vendor coordination and change categories, not in the initial build.
The initial build time with Sancho is not dramatically shorter than a skilled one-off integration. The difference compounds over years, in the maintenance debt that does not accumulate and the change projects that take days rather than months.
Read next: The Anatomy of a Mixed-Vendor Workcell: What Each Layer Actually Does