The back-office application to manage a fleet of robots and subscriptions

01Hardware tied to subscriptions needed a better way to track

Once Tessa moved from a closed beta to producing at scale, robots started leaving the assembly line as generic inventory rather than being built to order. That was good for production, but it left Tinybots Tinybots changed their name to Tessa Care in 2026. Source Tinybots changed their name to Tessa Care in 2026. Source with a real problem: Tessa’s services ran on a yearly subscription, an organization or individual owned the physical robot, but Tinybots provided the service behind it, and there was no longer a single order tying one device to one customer. We needed a system to track hardware, customers, and subscriptions.

02Mapping the flows of assembly, shipping, and contract activation

The different internal processes, how devices get built, shipped, and tied to a subscription, were mapped first, and an ideal flow designed from that map.

Several low-fidelity wireframes tested whether that flow covered every scenario, deliberately left rough so the conversation stayed on requirements rather than aesthetics.

The same rough treatment carried into two more screens: the subscription overview, and an individual robot’s own record.

Based on the mapping, we made a core decision: assembly and customer assignment had to become two separate events, so inventory could be managed independently from subscriptions and customers.

03Robots stayed unassigned until they shipped

Every robot got a unique hardware identifier as soon as it was built, and the dashboard tracked it from that point without tying it to any customer. A robot could ship to any organization once a customer was known, rather than being built specifically for a customer.

The changes were bigger than just an administrative dashboard: it meant I also had to rethink the whole assembly process and optimize the way Tessas got built and how they integrated into the workflow.

Each robot’s own record in the dashboard carried a small, deliberate set of fields: its serial number, the box number marking its physical spot on the shelf, the organization it belonged to and that organization’s online status, when its contract ended, and an open notes field for anything that didn’t fit a structured column.

Unassigned robots had a ship action, which started the workflow to ship an assembled robot and tie it to a customer (organization).

04A subscription starts the moment a robot comes online

The administrative dashboard had two views on the same data: one was Robots, intended first for managing inventory and looking at devices, the other was Subscriptions, intended for understanding which organizations had which devices, for support and contract management.

Subscriptions activated automatically after a set period following shipping, or the moment a device first connected to the internet, whichever came first.

The subscription view showed every contract’s online status, length, and payment details together, and once a deal closed, new invoices appeared showing which organizations needed devices shipped next. Each organization stayed tied to an external CRM for the surrounding customer data.

05Designing for scale, not for the first fifty robots

Running a pilot or a demo is forgiving: a spreadsheet and some improvisation can get you a long way. At scale, that model breaks down. With hundreds of subscriptions, contracts, and physical devices in motion, it quickly turns into an administrative nightmare.

Looking back, the real challenge was that there was nothing to improve on, no existing process to fix or streamline; it had to be built from the ground up. What made it complex wasn’t any single piece, it was combining CRM and subscription management, assembly, and inventory tracking and shipping into one system that held together.