Performance is a pre-build product for adult competitive cyclists in Germany. The athlete uses Telegram to talk to the AI Coach. The system uses the athlete's training plan, completed training, recovery data, and confirmed context.
This page is the full overview: goal, scope, tiers, boundary, architecture and delivery. For deeper detail, go to the prototype and the build specification.
Performance is a direct-to-consumer subscription: serious cyclists in Germany pay monthly to talk to an AI coach that understands their plan, their training and their recovery. The category is a conversation, not a tracker.
Real 1:1 coaching costs several hundred euros a month. Trackers like TrainingPeaks and WHOOP tell you what happened but don't talk to you. Between those two sits a conversational AI coach at a fraction of the cost.
Germany's cycling federation reports roughly 140,000 licensed racing members — the ceiling for "serious, structured-training cyclists". A small, specific audience: trust and relevance matter more than mass reach.
A direct-to-consumer subscription with two athlete-owned tiers. The athlete owns the account and approves every change.
The pilot proves the concept. It must show that athletes like the product, use it regularly and stay subscribed. It must also show that the product can be profitable. Only after that proof do we invest in the next version.
The product supports athlete-led training decisions. A coach can view selected information, but the athlete owns the account and approves changes.
| AI-supported self-coaching (what we build) | Autonomous AI coach (what we don't build) |
|---|---|
| Athlete owns the decision | AI is expected to own the decision |
| AI explains and suggests | AI prescribes |
| AI drafts possible plan changes | AI changes the plan automatically |
| Athlete can question, refine, accept or reject | Athlete is expected to follow |
| Engagement through conversation and insight | Engagement through delegated control |
Marketing can say "Your AI coach." The product boundary underneath stays fixed: AI-supported self-coaching for nonmedical cycling performance. Every feature decision is filtered through this line.
Both tiers are owned by the athlete. The difference is whether one existing professional coach gets a limited, read-only overview.
The work combines a Telegram conversation, a small web product, data integrations, and a controlled AI runtime.
These are excluded on purpose so the effort concentrates on the athlete product and AI quality first.
The athlete needs a quick daily view. The AI conversation supports decisions. The coach view shows selected shared data. These examples show the information hierarchy, not final visual specifications.
The athlete can revoke access at any time.
The product is not a general chatbot. The application must control what the AI can see, what it can do, and what the user can trust.
Send compact evidence objects with IDs, freshness, and deterministic values. Validate every cited fact. Do not let the model become the source of truth for numbers.
Allow the AI to explain and draft. Require athlete confirmation for plan changes, memory writes, and other state changes. Reject actions outside module authority.
TrainingPeaks access and its partner contract are not yet granted. WHOOP needs webhook handling, API refetch, reconciliation, freshness checks, and production approval.
Enforce athlete ownership and coach sharing rules on every read. Handle consent, export, deletion, retention, Mental Readiness evidence, and the medical boundary.
Use a durable PostgreSQL-backed job queue. Make syncs idempotent. Recover from missed webhooks. Do not lose messages or apply partial authoritative changes.
Deliver a reliable system for a controlled 20-athlete pilot. Measure latency, availability, projection freshness, backup restore, cost limits, and degraded behavior.
Deploy in Scaleway Paris (fr-par) to support EU data residency. Use one Next.js and TypeScript application, one PostgreSQL database, one durable worker, and one AI route.
Athlete browser -----------+
Coach browser -------------+
|
Telegram webhook ----------+--> Next.js application and API
| |
Stripe webhooks -----------+ +--> PostgreSQL state and job queue
+--> durable worker
Activity and recovery APIs ---------->+--> EU object storage
+--> AI gateway
|
+--> Scaleway Generative APIs, Paris | Component | V1 implementation | Purpose |
|---|---|---|
| Application | One containerized DEV1-L instance | Web, API routes, auth, billing, product logic |
| Database | DB-DEV-S Managed PostgreSQL | System state, evidence, and job queue |
| Worker | Supervised process on the same instance | Sync, reconciliation, AI jobs, and projections |
| Storage | Standard Multi-AZ object storage | Plan inputs, approved raw objects, exports, and backups |
| AI | One approved Paris model route | Conversation, planning, recovery, and safety workflows |
| Edge and secrets | Edge Starter, WAF, TLS, Secret Manager | Public access and protected credentials |
| System | Use | V1 rule |
|---|---|---|
| TrainingPeaks | Planned workouts, calendar, and completed activities | Mandatory. Read-only. No write-back. Approved commercial access and the partner endpoint contract are required. |
| WHOOP API v2 | Sleep and recovery | Mandatory. OAuth 2.0. Use webhook and API reconciliation. Production use above the 10-member development limit requires approval. |
| Telegram Bot API | Private athlete conversation | Private chats only. Verify the webhook secret. Deduplicate update_id before acknowledgement. |
| Stripe | Checkout, billing portal, and entitlement | Use Stripe-hosted pages and signed raw-body webhooks. Card data does not enter the application. |
| Scaleway Generative APIs | LLM route for all product domains | Paris route. Compare Gemma 4 and Qwen 3.6 on a fixed German corpus. Select one route before real-athlete use. |
The first release supports a controlled pilot. The Technical PRD defines the acceptance journeys; it is the current plan, not a fixed contract.
| Measure | Pilot target |
|---|---|
| Web availability | 99.5% each month, excluding announced maintenance |
| Provider sync | 95% of webhook or requested sync jobs within 2 minutes, if provider quota allows |
| AI response time | p50 <= 5 s and p95 <= 12 s. Provisional until benchmark. |
| Projection freshness | Within 5 minutes of a completed import or check-in |
| Backup | Daily encrypted off-provider backup. RPO <= 24 h and RTO <= 8 h. Monthly restore test. |
The build turns the scope into a working pilot system. It includes application code, provider contracts, AI controls, tests, and operations.