Show HN: Workout.cool – Open-source fitness coaching platform

Overall reception & use cases

  • Many commenters like seeing a polished, open-source alternative to commercial fitness apps, especially for weightlifting.
  • Common desired use cases: simple progress tracking, reusable routines, sharing programs with clients/friends, and an “inspiration browser” for exercises when equipment is limited (e.g., travel with bands only).

Onboarding, UX & platforms

  • Several users hit “Error loading exercises” and login issues, attributed to HN traffic and backend limits; fixes and infrastructure changes followed.
  • Strong demand for a mobile-friendly experience: PWA works now, but many argue a native app (or better offline-first behavior, proper back-button support) would improve discoverability and usability.
  • Required equipment + muscle selection confuses many beginners; they prefer goal- or template-based entry (“full body”, “fat loss”, “3x/week”) over anatomy-driven filters.
  • Others like muscle-first filters, especially for rehab or bodybuilding, and suggest toggling between equipment-first, muscle-first, and goal-based flows.

Workout generation quality & safety

  • Experienced lifters and trainers criticize current auto-generated routines:
    • Too many exercises per session (e.g., 33 for “full body”).
    • Naive selection (3 per muscle) without understanding overlap, volume, or ordering.
    • Inclusion of obscure/branded movements and equipment the user doesn’t have.
    • No sets/reps, 1RM percentages, progression, or difficulty scaling.
  • Several warn this can mislead beginners and increase injury risk; they recommend focusing first on logging, user-created templates, and community programs, plus better metadata (compound/isolation, primary/secondary muscles, movement patterns, difficulty).

Beginners, experts, and the value of apps

  • Debate over audience:
    • Some see it as a good on-ramp; others insist beginners should use very simple, proven programs (Starting Strength, 5x5 variants, PPL) plus in-person coaching for form.
    • Many argue habit and consistency matter more than sophisticated programming; apps mainly help with tracking and adherence.
  • Suggestions: preset, well-vetted templates; difficulty alternatives (“easier version of this exercise”); and possibly integrating respected free program bundles.

Data, videos, and licensing

  • Exercise videos come from a partner with explicit permission; prior project’s media licensing issues motivated a clean rebuild.
  • Commenters ask for non-YouTube animations and an open, reusable library of movement animations; cost and production complexity are major obstacles.
  • Other open projects (exercise datasets, wger, LiftLog, Liftosaur, etc.) are referenced; experiences range from enthusiastic to critical (UX and stability issues).

Architecture & technical choices

  • Backend exists to centralize the exercise DB, support shared routines, syncing, analytics, and potential integrations (Strava, Garmin, HealthKit, etc.); some wonder if a pure client-side or AT Protocol approach could avoid “HN hug of death” and hosting costs.
  • PostgreSQL was chosen for flexibility (JSONB, search, joins); a SQLite mode is suggested for simpler self-hosting.
  • Progress is stored locally during sessions and synced to the backend later; future plans include trend graphs and volume tracking.

Project history and trust

  • This is a spiritual successor to a previous open-source app that was sold and then stagnated; lack of response from the new owner led to a ground-up rewrite with a new stack and clean media rights.
  • Commenters ask whether it might be sold again; the maintainer emphasizes non-commercial motivations but acknowledges no hard guarantees exist in open ecosystems.