Swae OS
Health platform with federated backend
Workout programming, habit tracking, and journaling on an architecture designed to scale into AI coaching
Screenshots
Results
Programs
Coach → Client
templates, assignments, marketplace
Habits
Beyond workouts
lessons, gratitude, reflection
Federated
Backend
GQL stitching via Hive Gateway
Most fitness apps are either too simple (just log sets) or too complex (overwhelming dashboards nobody uses). Swae sits in the middle: structured enough for serious programming, simple enough to actually use.
Coaches create workout templates and programs, assign them to clients, publish to a marketplace. Clients enroll in programs and log workouts alongside habits. Exercise library with videos for every movement. Gratitude and reflection prompts sit next to freeform journaling. Meal tracking.
The backend runs GraphQL federation via Hive Gateway, stitching multiple services together. The architecture supports a multi-backend RAG system: Postgres for structured data, Qdrant for vectors, Memgraph for relationships.
The AI coaching layer isn't live yet. Due to how fast agentic AI has evolved since I started building, the original agent service got scrapped. The architecture is ready; when there's a product reason to spin up AI coaching, it's a deployment away. For now, the platform tracks workouts, manages habits, and supports structured reflection.
For Engineers
Architecture
Three federated services behind a Hive gateway. User service handles auth and profiles. Tracking service handles the high-write workout and meal logging. Knowledge service supports hybrid RAG (BM25 + vector) but is currently dormant, ready for AI coaching when there's a product reason to activate it.
Event-driven async indexing uses direct HTTP calls from the journal service rather than Celery or pub-sub. Keeps GCP costs down and avoids operational complexity that isn't justified yet.
The architecture is designed so the AI coaching layer can slot in as a fourth service behind the same gateway. When it ships, it'll have access to the full unified schema without requiring changes to existing services.
Key Decisions
Federation Over Monolith
Health data has different access patterns. Workouts are high-write, low-read. Knowledge queries are read-heavy, latency-sensitive. Federation lets each service optimize independently.
AI-Ready, Not AI-First
Built the data layer and architecture first. The coaching layer can slot in when there's a real product reason — not just because AI is trendy.
Habits Beyond Workouts
Fitness is behavior change, not just sets and reps. Gratitude journaling, evening reflection, lesson programs — the platform supports holistic coaching, not just workout logging.
What Was Hard
Building for a moving target.
- The original AI coaching vision is on hold, so the architecture needs to stay useful as a standalone product while leaving clean integration points for the AI layer
- GraphQL federation adds operational complexity; keeping subgraph boundaries clean as features evolve requires constant discipline
- Habit tracking UX is deceptively hard. Too much friction kills adoption; too little removes accountability
Stack