The Cloud-Native Workflow Behind Coco’s Next-Gen Delivery Robot

Building a delivery robot is one thing. Building one that survives Chicago winters, navigates rain-slicked Los Angeles streets, climbs steep gradients, and keeps running reliably, consistently, and at scale is something else entirely.

That’s the challenge Los Angeles-based Coco Robotics is solving with its next-generation delivery robot, the Coco 2.

At the core of the effort is a product development process powered by one truth: To build a reliable product, teams need reliable design tools.

A Delivery Robot Built to Handle Anything

The Coco 2 is Coco’s latest urban delivery robot, designed to operate in the kind of environments that would stop most robots cold. It’s larger in cargo capacity than its predecessor, built from tougher materials for better field performance, and faster. Swappable terrain-specific tires handle wet streets and snow. Powerful motors climb steep gradients. A zero-turn-radius capability lets it navigate tight sidewalks and crowded urban corridors. For rain, an air blade system uses directed airflow to clear water droplets from the robot’s sensors so it can see clearly in any weather.

On board is a solid-state LiDAR system for reliable object detection, improved cameras, better communications hardware, and an ambient light ring that signals the robot’s status and intent to people around it. Quick-swappable batteries make energy replenishment fast and simple in the field.

The Coco 2 is designed for a roughly two-mile delivery range and currently operates in cities including Los Angeles and Chicago with plans for rapid global expansion.

How Coco Balances Speed, Cost, and Quality

For Abhi Bhakuni, lead mechanical engineer at Coco, the core engineering challenge is straightforward to describe and difficult to solve: Build a product reliable enough to operate most of the time, across thousands of units, in dozens of environments, all while keeping cost and manufacturability in check.

“Reliability is really important,” he said during a webinar panel. “We want these robots to be operating most of the time.”

That means every design decision carries weight. Material choices, geometry, and structural design all get evaluated not just for performance but for how it holds up in the field and how practical it is to produce at scale.

Iteration is essential to get that balance right. But iteration only works if the process behind it is tight. Mistakes that reach manufacturing cost time, real money, and create downstream problems that ripple through the program. The faster a team moves, the more important it is that their data, their files, and their processes stay in sync.

Onshape-Arena Connection: One Source of Truth, Across Teams

Coco has been using Onshape for nearly 3 years, with Abhi personally on the platform for close to a decade. The company’s product development process runs through the tightly integrated Onshape-Arena Connection that keeps design data, BOM, and sourcing details aligned across the entire organization.

The workflow is straightforward in concept and significant in practice. Modeling happens in Onshape. When a design reaches a release milestone, the Onshape-Arena integration captures that data in a single shared system. From that point, everyone, including designers, supply chain teams, external vendors, is referencing the same version of a model. There is no ambiguity about which version a manufacturer is working from.

“The big difference with the Onshape and Arena integrate workflow is it’s like everything is aligned and files stay current,” Abhi said. “The release process is cleaner, more visible and … it’s really improved communication with vendors. In Arena, we can have our sourcing details very clearly laid down so our supply chain teams can just reference those. There is no confusion.”

For a team scaling globally, there's no room for a vendor working from the wrong file.

4 Things That Work Better with Onshape and Arena

The shift from a legacy file-based workflow to Onshape and Arena has changed how Coco’s team works in four specific ways.

1. BOM management is cleaner and more current. Design data flows directly from Onshape into Arena without manual export, keeping the bill of materials aligned with the live design at every stage
2. The release process is more visible. Every release is captured in Arena with a clear record of what was approved, when, and by who. There’s no chasing files or reconstructing decisions after the fact.
3. Vendor communication is more reliable. Sourcing details live in Arena alongside the design data, accessible to supply chain teams and external partners without requiring a separate handoff. Abhi notes this has meaningfully reduced confusion with overseas vendors who still work primarily from formal documentation.
4. The overall system stays current. Unlike file-based PDM environments, where assemblies break and syncing is manual, cloud-native design means the data is always up to date.

“In the past, I would have to be careful about managing data and communicating that carefully,” Abhi said. “Now I just share a link.”

A Platform That Keeps Getting Better

One of the less obvious advantages of building on Onshape is that the platform itself evolves on a consistent cadence – releasing updates every three weeks. For a team like Coco’s, iterating on a product that operates in the field every day, that matters. New features, improved workflows, and capabilities shaped by real customer feedback arrive regularly, without requiring upgrades, migrations, or IT intervention.

For Abhi, that consistency is part of what makes Onshape a reliable foundation for a fast-moving product development team.

“The platform is constantly evolving,” he said. “New features are coming in at a consistent cadence and it genuinely feels like it’s shaped based on user feedback and real customer needs.”

Building a reliable product is hard enough. The last thing a team scaling globally needs is to outgrow their tools.