Built a multi-product internal delivery platform. Solo. 34 contributors across 4 teams. Standups cut in half.

I joined Meta in August 2024 as a program manager and scrum master for analytics delivery. The team I dropped into was running fast on AI-native delivery work, with ceremonies and tooling that hadn’t been redesigned to match the pace.

The ticketing system was a daily complaint. Cards were created, assigned, dropped, and lost. Status meetings filled the calendar in their place. Engineers were doing more work than the tickets reflected. Managers were asking the same status questions in three places.

I used the same system the team did. I had the same complaints. The team didn’t need another status meeting and didn’t need a better ticket UI — they needed a different signal for what was actually happening.

I started building the signal myself.

Build the platform, not another tool

It started as a delivery-telemetry app to replace status meetings. It became a multi-product platform. Each product addresses a specific failure mode of the existing workflow.

I built each product, shipped it, and added the next when the team asked for it — or when I saw the next gap from inside the workflow myself. Some products replaced existing tools the team was already paying for (Miro and Lucidchart, retired by the retro tool). Others created signal that didn’t exist before (diffs-and-lines-shipped as the progress metric, replacing the broken task-open/close signal).

What each product solved

• Delivery telemetry + planning view. Replaces traditional status meetings with a live picture of what’s in flight, who’s blocked, and where workstreams collide. The planning view highlights conflicting tasks across teams before they’re scheduled together.
• Automated cross-workstream detection. A Scrum-Master-side system that surfaces cross-workstream collisions early. Not user-facing — but it’s the reason the planning view can flag what it flags.
• Retro tool with AI analysis. Retros used to live across Miro and Lucidchart. Now they run inside the platform, with AI surfacing patterns across sprints that humans miss when each retro is a fresh canvas.
• Internal AI assistant. Any team member can query delivery data in plain language — what was the biggest blocker last sprint — instead of digging through dashboards.
• Full insights dashboard. The visible surface of the analytics layer. Built for the people who want the data, not a chat.
• New progress metrics. Replaced the broken task open/close signal — devs don’t always create tickets — with diffs shipped, lines of code, and easy linking from a platform view directly to the source task or project. Progress that reflects what actually happened.
• Gamification layer. Gem store, custom games I built in, and icebreakers. Deliberately designed as an adoption strategy — people use the system more when there’s a low-stakes reason to open it daily.
• Manager view + AI recap chat. A self-serve surface for managers. Workload complexity per person, exec metrics on demand, and an AI recap they can converse with to pull what they need before a 1:1 or executive readout.

Underneath all of it, an async blocker workflow I built into my own daily digest catches blockers as they surface in chat and routes them to be resolved before the next standup.

Collapse the synchronous overhead

The standup cadence was 4 per week when I joined. Once delivery telemetry and the planning view were live, we cut to 3. Once the retro tool, the manager view, and the async blocker workflow were live, we cut to 2.

Half the synchronous overhead, no loss in delivery visibility — because the visibility moved out of meetings and into the platform.

Build for adoption, not for a demo

The system had to be one people actually opened. The gem store and icebreakers turned a tooling product into a daily destination. The manager view was built around what managers actually needed to pull before exec readouts, not what we thought they should track.

Engineers started requesting features unprompted — five engineers so far. That’s the signal. The system stopped being mine and started being theirs.

Half the meetings. No signal lost. The platform is still growing.

What I’d change is the order. I built the planning view and delivery telemetry first, then added retros, then chat, then metrics, then gamification. The right order would have been metrics first — the diffs-and-lines-shipped framework — because every other product on the platform got more powerful once the underlying signal stopped being broken. The early products were doing more work than they should have, to compensate for the broken upstream metric.

What I’d carry forward, and already am: the gamification layer is undersold as a feature category. It’s the reason the platform got daily use. Adoption is the product. Without daily use, the rest of the platform is a dashboard nobody opens.

The platform

Internal app at Meta. Built solo.

AI layer

Internal AI assistant, retro pattern analysis, manager AI recap. LLM-backed surfaces inside the platform.

Metrics framework

Diffs + lines of code shipped + project-task linking. Replaced task open/close as the progress signal.

Gamification

Gem store, custom games, icebreakers. Adoption-driving by design.

Automated detection system

Cross-workstream collision surfacing. Scrum-Master-side. Feeds the planning view.

Async blocker workflow

Integrated into my daily digest. Catches blockers before the next sync standup.