program planner
Timelines, resourcing, and roadmaps with one source of truth — and a client-ready view of the same data. Then it absorbed a forecasting tool and grew a second workspace.
team one internal tool, deployed in production on the agency's internal aws/eks platform.
Program planning for Team One Digital: project timelines, resource allocation, program-level roadmaps, and presentation views clean enough to put in front of Lexus stakeholders — all rendered from the same model, so the deck never drifts from the plan. Project snapshots give version restore; role-tiered auth separates admins from editors; PDF export matches the reference layout; and an API layer feeds program data to the intake bot, because the fleet talks to itself. It was also the first app migrated from consumer hosting to the internal platform — done the hard way, which is where the migration kit came from.
Two additions since. A colleague's forecasting and resource-allocation prototype — a browser-only app with its data in localStorage — was absorbed as gated views on the planner's own database: additive tables only, allocations at whole-project level with dev and maintenance bands derived from phases, a daily utilization engine, and auto-created lead allocations that carry their provenance (source=planner_project_lead) so no one mistakes a derived row for a human decision; the feature is gated by a flag that returns 404, not 403 — undiscoverable rather than forbidden. Then a workspace dimension (digital | national) carried in the session token with cross-workspace 404s, and a token-gated logical backup endpoint with a restore script.
Full case study in progress — artifacts pending clearance or writing time. The insight below is already earned.
Roadmaps are a rendering problem. One source of truth, rendered for the team and rendered for the client — the moment those diverge, both are fiction. Absorb adjacent tools as views on the same data, never as a second database.
the insight