Internal Product Build Case Study · Live Scorecard App

Two Layers, Three Tiers,
One Source of Truth

The team's metrics used to live in a scattered spreadsheet ritual. Now the whole weekly huddle runs inside a live app I built solo: a two-layer scorecard, a categorized revenue ledger with Stripe auto-pull, and every meeting surface in one place at team.whyinstitute.com.

2-layer
Scorecard: controllable weekly inputs plus quarterly rocks
1
Revenue ledger. Every dollar entered once, tagged once
Live
In production at team.whyinstitute.com, invite-only
The Before

Nobody could glance at the numbers and know if we were winning.

The WHY Institute runs on EOS: a weekly huddle, a scorecard, quarterly rocks, an issues list. The ritual was solid. The data underneath it was not. Metrics lived across a ClickUp list, a half-built local cockpit, and spreadsheets that had to be reassembled every week before the meeting could even start.

The deeper problem was structural. Outcome numbers and activity numbers sat side by side on the same board, revenue figures could be counted twice when one category overlapped another, and "what counts toward this metric" got re-argued in the meeting instead of settled once. Leadership wanted the equivalent of a big graph on the wall: where we were last quarter, where we are now, and where we are headed, visible to the whole team at all times.

No off-the-shelf dashboard modeled our huddle. So I built the app.

What I Built

The metric model came first. The code came second.

Before writing any application code, I researched how EOS actually defines scorecards, leading versus lagging measurables, and rocks, and wrote a metric model the team could approve. The core discipline: the weekly scorecard holds controllable inputs only. Every measurable has to pass one test: can the owner move it by Friday? Outcomes live on the quarterly rocks, never in both places. That single rule ended the drift and double-counting problems before the first table existed.

Then I built and shipped in phases:

  1. 01
    Metric Model
    Two-layer design: weekly leading inputs feed quarterly rocks, with an explicit mapping between them. Each metric carries a draft-to-lock lifecycle, so once a definition is locked, the "what counts" argument is over. A team questionnaire let each owner propose their own measurable.
  2. 02
    Deployed Shell
    Node/Express server on Render, Supabase for data and invite-only auth, and a static ES-module frontend with no build step. Realtime sync so every teammate sees the same numbers. Secrets stay server-side; nothing sensitive reaches the browser.
  3. 03
    Revenue Ledger + Stripe
    One categorized ledger: every dollar entered once, tagged once, with an "already in Stripe?" dedup flag. Stripe revenue auto-pulls in with a reconciliation view. The headline revenue rock is the sum of the ledger; the speaking rock is a computed slice of it, never typed and never additive.
  4. 04
    The Huddle Surface
    Wins, Issues/IDS (a solve requires an owner and a due date, and spawns a to-do), To-Dos with a done-done health percentage, a timed Run-the-Huddle mode, and a full-screen Present mode built for Zoom screen-share.
The Scorecard tab: a weekly table of controllable inputs with owner, target, moonshot and status, above a Rocks table of quarterly outcomes with pace badges
The Scorecard tab, the only place numbers are entered. Weekly inputs on top, quarterly rocks below. Each rock’s badge judges this week against its weekly share of the quarter goal. Shown in demo mode with placeholder numbers.
The Revenue Ledger: an entry row with week, category and amount, category totals, and rows marked manual or pulled from Stripe
The Revenue Ledger. Manual rows and Stripe pulls sit in one table, and a row marked “already in Stripe” is left out of every sum. That flag is what makes double-counting impossible.

The Command Center is the default view: a hero revenue pace chart plus a mini card per rock, each with three-tier pace lines for the progress, target, and moonshot goals. Status recomputes at quarter, month, or week granularity, so one bad week never paints the whole quarter red, and a plain-words pace line tells the team exactly what catching up requires. Week boundaries are computed by a single shared helper on one timezone, so a late-evening sale can never land in the wrong week for anyone.

The Command Center: the revenue rock with actual, progress, target and moonshot figures above a pace chart with three goal lines
The Command Center, the default view. One revenue pace chart with all three goal tiers, a plain-words pace line underneath, and a mini card for every other rock. Demo mode, placeholder numbers.
The Command Center in Week view: last week’s revenue against weekly progress, target and moonshot shares, with a hit-or-miss bar for each past week
Week view answers “did we do this week’s share?” and shows the catch-up amount needed to still hit target.
Present mode: the Command Center full screen on a dark background with no editing controls
Present mode: full screen with no edit controls, built for screen-sharing on the Zoom huddle.

Revenue is one ledger. The big rock is the sum, the speaking rock is a slice, and the system makes double-counting a payment structurally impossible.

The After

The whole huddle now runs inside the app.

The app is live in production and is the team's single source of truth for metrics. The weekly meeting opens in it, runs in it, and closes in it.

  • Live at team.whyinstitute.com on Render + Supabase, invite-only, with realtime sync across the team
  • The full weekly huddle runs in one surface: scorecard review, rocks, IDS, to-dos, and Present mode on Zoom
  • Stripe revenue auto-pulls into the categorized ledger with a reconciliation view, replacing hand-typed totals
  • Three-tier pace charts (progress, target, moonshot) readable at quarter, month, or week granularity
  • Draft-to-lock metric lifecycle, enforced by a database trigger, so locked definitions cannot quietly drift
  • Built solo by a marketer, with a no-build-step frontend the team can maintain
The Issues tab: a priority filter tied to the quarter’s three priorities, issues with an owner and a Solve button, and a row to add a new issue
Issues (IDS). The priority filter keeps the list tied to the quarter’s three priorities. Solving an issue requires an owner and a due date, and creates the to-do automatically.
What This Proves

Dashboards fail on data modeling long before they fail on code.

The hard part of this project was never the JavaScript. The hard part was deciding what deserves to be on a scorecard, writing rules that make bad data structurally impossible, and getting a whole team to trust one set of numbers. The app works because the model underneath it was argued out, written down, and approved before the first screen existed.

A single source of truth is a governance achievement with a UI on top. I built both halves.