RTSport — Product Development Roadmap

Author: Daedalus
Date: 2026-05-01
Status: Planning — Pre-MVP
Target: High school athletic departments in the US (v1.0)
Working directory: /home/hoffmann_admin/rtsport/

Table of Contents

1. Roadmap Overview — Phases & Milestones
2. Phase 0: Foundation (Now – Jun 2026)
3. Phase 1: MVP (Jul – Sep 2026)
4. Phase 2: Beta Partner (Oct – Dec 2026)
5. Phase 3: Compliance & Certification (Q1 2027)
6. Phase 4: Launch (Q2 2027)
7. Phase 5: Growth (Q3 2027+)
8. Revenue Model & Pricing
9. Licensing & Certification Requirements
10. Marketing & Branding Strategy
11. Testing Strategy
12. Risk Register
13. Decision Log

1. Roadmap Overview

Now          Q3 2026     Q4 2026     Q1 2027     Q2 2027     Q3 2027
┌──────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│ FOUNDATION│ │  MVP   │ │  BETA  │ │ CERTIFY│ │ LAUNCH │ │ GROWTH │
│ Mock, spec│ │3-views │ │ 1 school│ │FERPA/SSO│ │ 3 schools││ 10+    │
│ prototype │ │offline │ │ iterate │ │ SOC 2  │ │ 1 district││ districts│
└──────────┘ └────────┘ └────────┘ └────────┘ └────────┘ └────────┘
                │          │          │          │
            Core UX    Real data   Audit trail   Sales
            validated  feedback    complete      active

Guiding principle: Nothing ships to a real school without:
- FERPA-compliant data handling
- Audit logging
- Single sign-on (Clever/Google Workspace)
- A paper export path
- Explicit consent flows documented

Secondary principle: The prototype works offline first. Sidelines have terrible signal.

2. Phase 0: Foundation (Now – June 2026)

Goal

Validate core UX with mocked data. No backend, no real API. Clickable prototypes that Matt can show athletic trainer friends.

Deliverables

2.1 Product Package

• [x] Product brief (done — /shared/project-docs/rtsport/product-brief.md)
• [ ] CONTRACT.md — Formal API contract (Socrates territory)
• [ ] Roadmap (this document)
• [ ] Pitch deck — 8-slide: Problem → Solution → Market → Traction → Team → Ask

2.2 Clickable Prototype (v0.1)

• [x] AT Dashboard — active cases, quick entry, athlete detail overlay — live at /rtsport/at
• [x] Coach Dashboard — roster, restrictions, game-day view — live at /rtsport/coach
• [x] Parent Dashboard — child selector, recovery plan, timeline — live at /rtsport/parent
• [x] Shared Timeline component — phase bar, visibility tags — live at /rtsport/timeline
• [x] Notifications mock — push previews, in-app toast — live at /rtsport/notifications
• [ ] Sideline quick-entry — 3-tap injury log (athlete → body part → severity) — needs build
• [ ] Empty states — "No athletes on your roster," "No active injuries," "First day of season" — needs build
• [ ] Offline mock — ServiceWorker or manifest to demo offline capability — needs build

2.3 Design System

• [x] CSS design tokens (rtsport.css — dark mode, role colors, spacing)
• [ ] School theming system — CSS custom properties for logo, primary/accent colors, sport naming. Single override file.
• [ ] Typography scale — Formalize: 0.625rem / 0.75rem / 0.875rem / 1rem / 1.25rem
• [ ] Icon system — Decide: inline SVGs vs icon sprite vs emoji fallback

2.4 Architecture Decisions (with Socrates)

• [ ] Data model — Athlete / Case / Event / Milestone / Restriction / Message
• [ ] Auth system — JWT + session cookies (borrow from HoffDesk auth module)
• [ ] Storage — SQLite for single-school? PostgreSQL for multi-school?
• [ ] Offline sync — ServiceWorker cache + IndexedDB for local data; sync when online

2.5 Validation

• [ ] Show prototype to 1 LAT (Matt knows one?)
• [ ] Show to 1 coach
• [ ] Show to 1 parent
• [ ] Record session — where do they tap? What confuses them?

3. Phase 1: MVP (July – September 2026)

Goal

Working app with real data flow for one imaginary school. All views functional with mocked backend. Runs on Beelink for internal demo.

Deliverables

3.1 Backend (Socrates)

• [ ] FastAPI routes for mock data — GET /api/rtsport/athletes, GET /api/rtsport/cases, POST /api/rtsport/events
• [ ] SQLite seed database — 3 sports, 40 athletes, 8 active cases, 2 past cases
• [ ] Auth endpoints — login/register (school staff), role assignment (at / coach / parent)
• [ ] Family association — link parent accounts to athlete profiles
• [ ] Webhook — for real-time notification (optional v0.1 fallback: polling)

3.2 Frontend (Daedalus)

• [ ] Wire all views to real API — replace mocked HTML with Jinja2 templates
• [ ] Sideline quick-entry — 3-tap form, auto-saves draft
• [ ] Bottom sheet overlay — replace full-screen modal on athlete detail
• [ ] Search / filter — AT dashboard: search by name, filter by sport, sort by severity
• [ ] Coach game-day view — roster sorted: restricted first, "can play" indicator
• [ ] Parent child-picker — works for 1-4 kids, dropdown fallback for 5+
• [ ] "Who sees this" banner — persistent on every note entry form
• [ ] School theming — load CSS variables from backend config (per-school config object)

3.3 Core UX Fixes (from v0.1 critique)

• [ ] Severity hierarchy on AT dashboard — urgent → warning → stable, grouped visually
• [ ] Tap target minimum 44pt — increase athlete row hit area
• [ ] aria-labels on all icons and status badges
• [ ] Collapsible timeline on parent view (past events hidden by default)

3.4 Infrastructure

• [ ] subdomain decision — rtsport.hoffdesk.com? Or separate domain?
• [ ] Database migrations — Alembic or manual SQL files
• [ ] Backups — Daily DB dump to S3-compatible storage

4. Phase 2: Beta Partner (October – December 2026)

Goal

One real high school uses it. Not a paid pilot — a design partnership. Real athletes, real injuries, real parents.

Critical: You can't just show up with software. You need:

4.1 Recruiting a Partner School

• Target: Local Green Bay area school (Preble? Bay Port?) or Matt's alma mater
• Relationship: Find a LAT who's frustrated with their current tools
• Pitch: "Free for the season. You tell us what's broken. We fix it before we sell it."
• Get in writing: Letter of agreement (not a contract) — they get free software, we get feedback rights + case study permission

4.2 Required Before Any Real Data Touches the Server

• [ ] FERPA compliance documentation — Written data handling policy
• [ ] District IT approval — They need to sign off on the system
• [ ] Parent consent flow — Opt-in for parent portal access
• [ ] Data retention policy — What happens at end of season? End of school year? Athlete graduation?
• [ ] Breach notification plan — Required by 20+ state laws

4.3 Beta Features

• [ ] Roster import — CSV upload from the school's SIS or sports management system
• [ ] Email notifications — Parent gets email when injury recorded (not just push)
• [ ] PDF export — One-click: athlete recovery summary for coach's clipboard, doctor's visit
• [ ] Basic reporting — "Number of injuries this season," "Average RTP time by sport"

4.4 Beta Feedback Loop

• [ ] Weekly 15-min check-in with LAT
• [ ] Monthly survey to parents who received notifications
• [ ] Public bug board (GitHub Issues or similar)
• [ ] Feature request tracker — what do they ask for unprompted?

5. Phase 3: Compliance & Certification (January – March 2027)

Goal

Meet the legal and procurement requirements for school districts to buy the product.

5.1 Regulatory Compliance

5.2 Security Certifications

For a school to buy software, they typically require:

Strategy: Achieve SOC 2 Type I before first paid customer. Use it as a marketing differentiator — most competitors don't have it.

5.3 Contract Requirements

• Data Processing Agreement (DPA) — Required by most school districts
• Business Associate Agreement (BAA) — Not needed (covered entity exemption), but offering it is a trust signal
• Standard School Vendor Assessment — Every district has one; prepare a response packet
• Insurance — Cyber liability ($1M minimum), general liability. Required by district procurement.

5.4 Audit Features (Engineering)

• [ ] Audit log — Every view of an athlete record is logged: who, when, what fields
• [ ] Data deletion pipeline — Parent or school can request athlete data destroyed; cascade delete within 30 days
• [ ] Data export — School can export all their data as CSV/JSON at any time
• [ ] Session timeout — Auto-logout after 15 minutes inactivity
• [ ] IP allowlisting — Districts can restrict access to school IP range
• [ ] Role-based access control (RBAC) — Verified on every request, not just client-side

6. Phase 4: Launch (April – June 2027)

Goal

3 paid schools onboarded. Revenue covers hosting costs. Ready for sales to scale.

6.1 Pricing (see Section 8 for detail)

• Free tier: Single school, 1 sport, up to 20 athletes
• Paid tier: Per-school annual license
• No per-athlete pricing (creates perverse incentive to under-report)

6.2 Sales Materials

• [ ] One-page sell sheet — Problem → Solution → Price → Compliance
• [ ] ROI calculator — "Athletic trainer saves X hours/week" (time they currently spend on communication)
• [ ] Security packet — 10-page doc answering every question a school IT department will ask
• [ ] Demo video — 3-minute walkthrough (the AT, coach, and parent views)

6.3 Launch Channels

• NATA (Nat'l Athletic Trainers' Assn) — Conference? Exhibitor booth? Cost: $1,500–5,000
• State AT associations — Wisconsin, Illinois, Michigan — newsletter ad: ~$200
• Athletic director conferences — WIAA, NFHS — these are the budget holders
• Direct email — Scrape public school staff directories (slow, manual, but zero cost)

6.4 Customer Success

• [ ] Onboarding checklist — 30-minute setup call, roster import, parent invites
• [ ] Help center — 5 articles: getting started, data privacy, billing, troubleshooting
• [ ] First-week check-in — Automated email + optional human call

7. Phase 5: Growth (July 2027+)

Goal

10+ schools or 1+ district with multiple schools. Team of 2+ (need a sales or customer success person).

7.1 Product

• [ ] District dashboard — See all schools, compare injury rates
• [ ] Advanced reporting — Injury trends by sport, season, grade level
• [ ] Integration marketplace — Sync with SportsWareOnLine, ATGenius, Healthy Roster (Phase 2 of compliance story)
• [ ] Mobile app — Not a PWA. Native iOS/Android push, camera for injury photos, offline-first sync. This is critical for AT adoption.
• [ ] Telehealth — Parent requests a call, AT schedules video check-in

7.2 Business

• [ ] SOC 2 Type II — Required for districts >2,000 students
• [ ] Channel partner — Sell through sports medicine distributors (Mueller, Cramer)
• [ ] Reseller program — Independent ATs who recommend the tool get a cut
• [ ] Grant funding — CDC concussion grants, state athletic safety initiatives

7.3 Team

• v1: Matt (product/vision), Daedalus (design/frontend), Socrates (backend/infra)
• v1.5: Part-time sales person (commission-only, ex-AT preferred)
• v2: Customer success (handles onboarding + support)

8. Revenue Model & Pricing

8.1 Philosophy

• Free to athletes/parents — Always. That's the adoption moat.
• Pay to schools/districts — They have budgets for "athletic safety software."
• Price by school size, not by feature — Simpler to buy, simpler to sell.

8.2 Pricing Tiers

8.3 Justification

• ATGenius charges $299–799/yr for a single AT. We're competing on value (communication, not just charting).
• Healthy Roster charges per athlete — our flat school fee is easier to sell to an athletic director.
• At $1,500/school, breakeven is ~3–4 schools (hosting + cert costs).
• District pricing ($7,500+) is where the real revenue is. A 5-high-school district at $1,500 each = $7,500; bundled at $12,000 is a better deal for them.

9. Licensing & Certification Requirements

9.1 Federal

9.2 State Law (Wisconsin — Primary Target)

9.3 Key Compliance Actions (Before Beta)

1. FERPA: School Official Designation — Each partnering school must formally designate RTSport as a "school official" with a legitimate educational interest. This is a written agreement, not a contract.

2. Data Classification — Label all athlete health data as "treatment records" under FERPA (not "education records"). Treatment records have stricter access controls: parent can view, but generally cannot demand destruction.

3. Directory Information Opt-Out — Some parents opt their kids out of all directory info. The system must handle this: those athletes should not appear in coach-facing team lists by name.

4. Data Minimization — Only collect what's needed for RTP management. No marketing profiles. No analytics beyond product usage.

5. Destruction Policy — WI § 118.125 requires destruction when no longer needed for educational purposes. Define: athlete graduates → destroy non-directory records after 1 year.

9.4 Certification Sequencing

Phase 2 (Beta)    → FERPA-compliant data handling + written policies
Phase 3 (Cert)    → SOC 2 Type I audit + penetration test
Phase 4 (Launch)  → SOC 2 Type I report available to prospects
Phase 5 (Growth)  → SOC 2 Type II + WCAG 2.1 AA audit

10. Marketing & Branding Strategy

10.1 Brand Architecture

Name: RTSport (working title — test this with a LAT)
Tagline candidates:
- "Return to play, together."
- "The shared timeline for athletic health."
- "From injury to clearance. Everyone in the loop."
- "Side by side. From sideline to clear."

Visual identity:
- Logo: Shield or chevron + a timeline arc. Not a medical cross (too clinical, doesn't say "sport")
- Colors: Keep the teal (AT — clinical confidence), amber (coach — action), violet (parent — care) system. It works and it's differentiated.
- Font: Inter (system-level, fast loading). No custom display font.
- Mood: Clean, confident, warm. Think Nike's healthcare arm. Not hospital cold, not consumer silly.

10.2 Positioning

One-liner: RTSport gives every athletic trainer, coach, and parent one shared view of an athlete's return-to-play journey.

Competitive positioning:
- VS SportsWareOnLine: "We don't replace your EMR. We make it useful to the people who need to know."
- VS ATGenius: "Purpose-built for communication, not just documentation."
- VS Healthy Roster: "The same idea, but built for the way ATs actually work — offline first, mobile native, FERPA-native."
- VS nothing: "Your current system is texts and paper. This costs less than a set of practice jerseys."

10.3 Go-to-Market Channels

10.4 Content Marketing

• Blog series: "The Communication Gap in High School Sports" — 3-part series on hoffdesk.com
• Template: "Sample FERPA-Compliant Parent Consent Form for AT Communication" — downloadable PDF
• Case study: Document the beta school experience (with permission)
• One-pager: "Why Your Athletic Trainer Needs Better Tools" — for ADs to give to principals

11. Testing Strategy

11.1 Unit Tests

• Backend: pytest for all API routes. Mock the database. Test every role-permission combination.
• Frontend: Minimal — the app is server-rendered HTML. Test template rendering for edge cases (empty roster, 500 athletes, athlete with no parents).

11.2 Integration Tests

• API contract tests: Every endpoint returns expected shape for each role
• Auth flow: Login → session → logout → protected route → redirect chain
• Parent linking: Create athlete → create parent account → link → verify parent sees only their child

11.3 UX Testing

• Prototype testing: Before any code, test mockups with:
• 1 LAT (15 min — can they do the core task?)
• 1 coach (5 min — can they find tonight's lineup?)
• 1 parent (5 min — can they find their kid's status?)
• Beta logging: Record every API call during beta. Find the patterns. What do ATs load most? What do parents ignore?
• Session recordings (if ethics OK during beta): Heat map of clicks on each dashboard.

11.4 Performance Testing

• Load test: 50 concurrent ATs querying rosters simultaneously. Target: <500ms response time.
• Offline test: Load the app on a phone in airplane mode. Does cached data render? Does it gracefully degrade?

11.5 Security Testing

• Penetration test: Before SOC 2 audit. Expect: OWASP Top 10 scan (XSS, CSRF, SQLi, IDOR).
• Role escalation: Logged-in as parent, try to access /api/rtsport/athletes (should return 403).
• Rate limiting: Login attempts, API calls per user per minute.

11.6 Definition of Done (Every Feature)

[ ] Code reviewed (by Socrates or self-review checklist)
[ ] Unit tests written and passing
[ ] Integration test passes
[ ] Accessible: keyboard navigable, aria labels, 4.5:1 contrast
[ ] Mobile phone test: renders at 375px width
[ ] Offline test: degrades gracefully
[ ] Audit log: all writes are recorded
[ ] Error state: bad data shows helpful message, not 500 page

12. Risk Register

13. Decision Log

This roadmap is a living document. Update as you learn from the beta school, the market, and the certification process.

Next action: Review with Matt. Approve Phase 0 and Phase 1 scope. Start the CONTRACT.md conversation with Socrates.