Roadmap-Tool.
Eigenes Sprint-Planning — weil Linear, Jira und GitHub Projects nicht passten.
Standard-Tools haben die falsche Granularität.
Linear ist gebaut für Tickets in einer Engineering-Organisation. Jira hat zu viele Knöpfe. GitHub Projects ist eine bessere Excel-Tabelle. Keines dieser Tools versteht das Konzept eines Sprints mit sieben Phasen, Kunden-Abnahme zwischen E und F, und einer Capacity, die aus den letzten zehn Retros gelernt wird.
Außerdem: Single-User. Niemand braucht Multi-Tenant-Berechtigungen für ein persönliches Sprint-System. Die ganze Auth-Komplexität ist Overhead.
Eigenes Tool, Pattern A: Astro + Supabase-Direct.
Das Roadmap-Tool ist ein Sprint-Board mit Drag-Drop, Backlog-Sync zu Markdown-Dateien, Notion-Bridge und automatischem Pack-Algorithmus. Live unter roadmap-escholly-ship-its-projects.vercel.app. Sprint 233 wurde es komplett refactored — Astro 5 statt Next.js, Browser-Direct zu Supabase, kein Server-Hop.
Effekt messbar: Active CPU von ~65 Sekunden pro Tag auf unter 2 Sekunden. Hobby-Tier reicht jetzt für unbegrenzt offene Tabs. Pattern A skaliert auf Cookmark 2.0 (Sprint 240) und PhysioGPT 2.0 (Sprint 239).
/ tech-decisions
Drei Entscheidungen, die wichtig waren.
Architektur
Astro + Supabase-Direct
Sprint 233 Migration weg von Next.js + Vercel-Functions. Browser spricht direkt mit Supabase per anon-Key + JWT. Vercel hostet nur Static Assets — null Active CPU im Hobby-Tier.
Realtime
Supabase postgres_changes statt Polling
Ältere Version pollte alle 30 Sekunden. Neue: WebSocket-Subscription auf roadmap_items. Bei Änderung kommt Update als Event — keine Roundtrips, kein Polling-Overhead.
Pack-Algo
Empirische Capacity-Kalibrierung
Sprint-Budget liest aus retros.md. Nicht hardcoded. P50 + P75 + Sweetspot pro Quartal aus echten Sprint-Outputs. Pack-Algo schlägt Sprint-Inhalt automatisch vor.
/ weitere apps