Roadmap Tool.
Custom sprint planning — because Linear, Jira and GitHub Projects didn't fit.
Standard tools have the wrong granularity.
Linear is built for tickets in an engineering organisation. Jira has too many knobs. GitHub Projects is a slightly better Excel sheet. None of these tools understand the concept of a sprint with seven phases, customer sign-off between E and F, and a capacity learned from the last ten retros.
On top of that: single-user. No one needs multi-tenant permissions for a personal sprint system. The whole auth complexity is overhead.
A custom tool, Pattern A: Astro + Supabase-Direct.
The Roadmap Tool is a sprint board with drag-and-drop, backlog sync to markdown files, Notion bridge and an automatic pack algorithm. Live at roadmap-escholly-ship-its-projects.vercel.app. Sprint 233 refactored it completely — Astro 5 instead of Next.js, browser-direct to Supabase, no server hop.
Effect is measurable: active CPU dropped from ~65 seconds per day to under 2 seconds. The hobby tier now handles unlimited open tabs. Pattern A scales to Cookmark 2.0 (sprint 240) and PhysioGPT 2.0 (sprint 239).
/ tech-decisions
Three decisions that mattered.
Architecture
Astro + Supabase-Direct
Sprint 233 migration away from Next.js + Vercel functions. Browser talks directly to Supabase via anon key + JWT. Vercel only hosts static assets — zero active CPU on the hobby tier.
Realtime
Supabase postgres_changes instead of polling
Older version polled every 30 seconds. New: WebSocket subscription on roadmap_items. Updates arrive as events — no roundtrips, no polling overhead.
Pack Algo
Empirical capacity calibration
Sprint budget reads from retros.md. Not hardcoded. P50, P75, sweetspot per quarter computed from actual sprint output. The pack algorithm proposes sprint contents automatically.
/ other apps