CourtIQ 🎾

One-liner: Smart tennis training app — helps amateur players learn and practice “percentage plays” (the high-probability shot choices that win more points), then tracks and analyzes their decision-making over time.

Origin: Moved here from uloza/courtiq (now runquest/courtiq, private). A second, uncommitted local repo courtiq.club holds the data pipeline and content-generation work (see below).

Stack: Rails 7.2 + Hotwire/Turbo, Tailwind CSS, Docker-based dev environment, PWA (offline-capable).

Core loop:

• Learn — situation library with interactive SVG court diagrams, risk/reward scoring per shot choice
• Log — quick-log practice decisions (good choice / risky choice / error), offline-capable with sync
• Analyze — session summaries, percentage-game score trends, pattern/leak detection

Roadmap (from MILESTONES.md):

• M1 — MVP: foundation, situation library, practice logger, mobile UX (bottom nav: Library/Log/Progress)
• M2 — Match integration: opponent profiles (play-style templates), match strategy builder, post-match pattern analysis
• M3 — Analytics & growth: advanced analytics, content/learning, optional community, polish

Actual status as of 2026-09-23 (verified against GitHub):

• Rails app: Foundation epic done (Hotwire/Turbo, PWA manifest + offline service worker, Tailwind, DB schema for situations, professional tennis stats data integrated) — last real feature commit 2026-02-05. Every push since then has been Dependabot dependency bumps only; no feature work in ~7 months.
• Situation library content (the actual percentage-play data) is not populated yet — issues #57-60, #62-63 (shot success rates from data, situation taxonomy, player profile structure, shot preference tracking) are open and unstarted.
• Practice Logger, Match Integration (M2), and Analytics (M3) epics: not started.
• courtiq.club (separate local repo, no commits yet): a Phase 1 data pipeline (app/PHASE1.md) that pulls Jeff Sackmann’s Match Charting Project data, normalizes it, and validates ~20 situations against real shot outcomes to derive the percentages the Rails app’s situation library needs. Raw data (~200MB CSVs) is pulled; the normalize/validate steps haven’t been run yet, so no zone_percentages.json output exists.
• Same courtiq.club repo also has a working Instagram content pipeline (brand guidelines, fonts, logo, generate_carousel.py) that has already produced ~8 real content pieces (e.g. “myth_strongest_wins”, “what_choking_actually_is”, “serve_that_wins_free_points”) — none published yet, all sitting uncommitted locally.

Next steps to launch (from the 2026-09-23 B2B-pivot brainstorm):

1. Finish Phase 1 in courtiq.club (run 04_normalize.py / 05_validate.py, hit the ≥15/20 PASS bar) so the situation library has real data instead of a schema.
2. Decide positioning before building further: sell to individual amateur players (consumer, high-volume) vs. sell to coaches/academies (B2B, per-seat/per-academy pricing, far fewer customers needed for meaningful revenue — see [[courtiq-academy-pivot notes in raw ideas]]).
3. If going B2B: add a coach-facing multi-student dashboard on top of the existing practice-logger/analyze loop, and package pricing per academy rather than per player.
4. Publish the already-generated Instagram content under the courtiq.club brand to start building an audience/funnel regardless of which path is chosen.
5. Line up 5-10 target academies or coaches for pilot outreach/demo calls once the dashboard exists.

Status: Real, active build — not a raw idea. Foundation is real and working; the situation-library data and every feature epic past Foundation still need to be built.