Relay

Challenge

Growing teams often run on tools that were never designed to talk to each other. Status lives in meetings. Relay had to make ownership and progress visible without becoming another heavyweight suite.

Context

The concept is for product and operations organizations that need a shared picture of work across squads, without forcing a rigid methodology on every team.

Strategy

We designed Relay as a thin operational layer: work items, cadences, and signals. Integrations bring activity in. The product does not try to replace every specialist tool.

Design approach

Boards, lists, and insight cards share one visual language. Density is high, but hierarchy is strict. Purple is reserved for the thing that needs attention now.

Architecture

A Next.js application with a Node API and MongoDB for flexible work documents. Event ingestion and digest jobs run as isolated workers. Dockerized services keep local and cloud environments aligned.

Implementation

We shipped the core object model first (work, owner, status, signal), then layered views and integrations on top of it.

Solution

Relay gives leadership and teams the same picture of progress. It is intentionally incomplete in the right ways: it coordinates work instead of attempting to contain every workflow.

Results

• A durable object model that views and integrations can share.
• An internal product that feels as considered as a customer product.
• A cloud setup that a small platform team can operate.

Learnings

• Internal tools fail when they demand a new religion.
• Status should be a byproduct of work, not a separate reporting task.