Zoe Admin

Zoe Admin is an administration application for Zoe voice-assistant speakers installed in more than 2,000 cabins on a cruise ship. It brings speaker management, access control, and speech-service monitoring into one workspace for the teams responsible for the experience.

The problem

Operating voice-assistant speakers at cruise-ship scale means looking after far more than an individual unit. Teams need to manage Zoe speakers across thousands of cabins while also understanding the health of the servers that support the voice experience.

Those servers run trained models for both text-to-speech and speech-to-text processing. Zoe Admin makes the speaker fleet and its supporting infrastructure visible in one place, while role-based access control keeps administrative capabilities aligned with each team member's responsibilities.

Role and collaboration

I worked on the administration application as part of the product team. My contribution focused on developing the interface and the workflows used to manage Zoe speakers; the platform itself was a shared team effort rather than a solo project.

The application combined an AngularJS frontend with Express services running on Node.js. The admin backend also communicated with Python microservices developed by another engineering team. The teams shared typed RPC contracts implemented with gRPC and Protocol Buffers, keeping service boundaries explicit while allowing each team to work in its own stack.

Platform architecture

The admin experience had to connect two operational layers. The first was the fleet of Zoe speakers installed across more than 2,000 cabins. The second was the server infrastructure behind speech recognition and voice generation.

AngularJS provided the structure for data-heavy administration views, while Express powered the server-side application layer. From there, gRPC calls and Protocol Buffers schemas connected the admin application to the Python microservices owned by the other development team. RBAC formed a core part of the product model, ensuring that access to administrative areas and actions followed defined roles.

The full infrastructure was containerized with Docker and orchestrated as a Docker Swarm cluster. Portainer served as the operational UI for inspecting and managing stacks, services, containers, and nodes without requiring every routine action to be performed from the command line.

Operational visibility

Zoe Admin surfaced server metrics alongside cabin and speaker management. This gave the team a shared view of the Docker Swarm environment supporting the assistant, including the Python services running trained text-to-speech and speech-to-text models. Portainer complemented the product interface with infrastructure-level visibility and controls.

Bringing these signals into the same admin application reduced the distance between a cabin-level issue and the infrastructure context needed to investigate it. The interface was designed as an operational command center rather than a collection of isolated dashboards.

Outcome

The resulting platform supports the day-to-day management of Zoe speakers across more than 2,000 cruise-ship cabins. It combines speaker operations, RBAC, gRPC-based microservice integration, and visibility into Docker Swarm infrastructure in one administration experience built by multiple collaborating teams.

The project reinforced a principle that matters in complex internal products: the interface should expose the relationships between users, devices, and infrastructure without making operators reconstruct those relationships themselves.