Product

What’s actually built, what’s spec’d, and how the three surfaces (Owner, Trainer, Member) cohere into one operating system.

Refreshed July 2026. What’s-built content verified by code audit (May 2026); live URLs included throughout.

1. Value proposition (one paragraph, both audiences)

For independent gym owners: GymStack runs your gym’s billing, member management, check-ins, workout/diet plans, leads, and member app — all from a single dashboard, with UPI Autopay, WhatsApp Business automation, and 5% GST invoicing as the target renewal workflow. Set up in 24 hours, ₹999/month to start.

For members: A branded gym app on your phone — see today’s workout, log sets, scan in, pay your fee, talk to your trainer, see your progress, all in one place.

2. What is built and shipping today

Verified by code audit of the monorepo (May 2026). These are not roadmap items — they are live and serving traffic.

Live URLs

Admin dashboard — 12 pages, all functional

Member app (Flutter, 8 screens end-to-end)

API — 11 routes, 59-table multi-tenant schema

Schema completeness: gymId foreign key on all tables (multi-tenant isolation), member lifecycle (active/inactive/expired/frozen), membership plans with duration/renewal, payment method enums (UPI/card/netbanking/cash), check-in methods (QR/biometric/manual), exercise metadata (category/difficulty/muscles/equipment/GIF URL), workout groups (standard/superset/circuit/dropset), lead pipeline (new → contacted → trial → converted/lost), soft deletes, timestamps.

3. What is NOT built — the gating items

These are the operational dependencies in /strategy and /gtm. Each is sized below.

Out of Year 1 scope (intentionally)

• AI churn prediction (the predictive ML model) — needs labeled data we won’t have until M9+. Caveat: retention/churn-AI is now table-stakes at the top of the market — ABC Glofox ships a 40M-member churn model and India’s Kore App ships “Predictive Retention AI” (churn flag up to 60 days out); see /competitors §4 [M]. So Year 1 ships the rules-based at-risk surface already live in the dashboard (§5 Flow 3, /analytics churn), and the predictive ML layer is a fast-follow competitive necessity — not a differentiator to pitch.
• Offline mode (promised on marketing page but not a Year 1 priority — gyms in tier-2/3 have intermittent but available connectivity)
• Biometric check-in (enum exists; iOS/Android implementation is M9+ or vendor partnership)
• Email delivery for invoices (WhatsApp + SMS is sufficient for the buyer)
• Corporate wellness aggregator surface (Year 2)

4. Pricing — single source of truth

Pricing is published, not “request a demo.” Indian SMB buyers read hidden pricing as a signal they’re not the target.

Three tiers by design. The v1 business plan carried a fourth Enterprise (₹9,999+/mo, multi-location chains) tier; it is intentionally deferred to Year 2 so the validation phase sells only Starter / Growth / Pro and keeps pricing legible. Enterprise returns when a chain (the Rajesh persona) needs multi-location + dedicated support.

Add-ons (Year 1):

• Transaction fee: 1% on UPI/card transactions through GymStack (optional; defaults off)
• Premium content pack: ₹500/mo — 200+ professionally-shot exercise videos + 50 diet templates
• Extra location (Pro): ₹2,999/mo per additional location

Annual discount: 2 months free on annual plans (we offer it but don’t push; monthly is the default to lower buyer risk).

Why these prices

Anchored against:

• KriyaX at ₹499/mo — we are 2x but ship a real member app
• GymOwl annual pricing — local competitors can be inexpensive; we must win on product workflow and onboarding, not price alone
• Mindbody Starter $99/mo (~₹8,300) — our Pro is 40% below
• Vagaro $30/mo + $10/staff — Indian gyms average 2-5 staff, so Vagaro lands at ~₹4,000-6,000; we beat at Growth

These prices feed directly into the FINANCIALS MRR model.

5. User flows (the critical paths)

Flow 1 — Owner signs up and onboards

1. Marketing site CTA "Start free 14-day trial"
   ↓
2. Phone + OTP (no email, no password)
   ↓
3. Gym profile (name, address, branding color, logo upload)
   ↓
4. Plans setup wizard (suggest defaults based on member count)
   ↓
5. CSV upload OR manual entry of first 10 members
   ↓
6. UPI Autopay mandate setup (Razorpay flow)
   ↓
7. WhatsApp Business connection (optional, can defer)
   ↓
8. First member added → app delivers welcome WhatsApp with member app download link

Target: <24 hours from signup to first paying member through GymStack.

Flow 2 — Member uses the gym for the first time

1. Receives WhatsApp with member app link + onboarding code
   ↓
2. Installs app, phone OTP login
   ↓
3. Fitness profile (goals, experience, injuries) — 5 questions
   ↓
4. Personalized plan generated (using exercise catalog + goal)
   ↓
5. Walks into gym, scans QR at front desk → check-in logged
   ↓
6. Opens "Workout" tab, sees today's plan
   ↓
7. Logs sets as they go (rest timer auto)
   ↓
8. After session: PR celebration if applicable, weight log, optional progress photo
   ↓
9. Push notification next day reminding them of next session

Flow 3 — Renewal & save

T-7: WhatsApp template "Hi <name>, your membership at <gym> expires on <date>. Renew with one tap: <UPI link>"
   ↓
T-3: Same, with the gym owner CC'd if it hasn't been clicked
   ↓
T-0: If autopay mandate exists, debit. If not, push + WhatsApp.
   ↓
T+1: If failed, "at-risk" surface in owner dashboard with 1-click WhatsApp call template
   ↓
T+3: Owner sees them in "expired" list. Can manually offer winback discount.

Flow 4 — Trainer assigns a plan

1. Trainer opens trainer app, sees today's clients list (5-12 people)
   ↓
2. Taps client → sees their workout history + last 4 weeks of progress
   ↓
3. "Assign plan" → picks template OR builds custom
   ↓
4. Custom flow: search exercises (typeahead over 1,500), drag into day, set sets/reps/load
   ↓
5. Add notes per exercise (form cues)
   ↓
6. Assign → client gets notification, plan appears in their member app

Flow 5 — Owner reviews their business (Sunday weekly ritual)

1. Opens admin dashboard on phone OR laptop
   ↓
2. Top section: This week vs last week — MRR, new members, churned, check-ins
   ↓
3. At-risk list: members who haven't checked in 7+ days
   ↓
4. Expiring list: memberships expiring this week
   ↓
5. Lead pipeline: where new leads are stuck
   ↓
6. Decides 3 actions: nudge X members, follow up Y leads, plan next week

6. Journey maps

Owner — first 90 days

Member — first 30 days

Trainer — daily

7. Platform architecture (one diagram in words)

[ Member Flutter app ]    [ Trainer Flutter app ]    [ Admin Next.js ]
        |                          |                          |
        '---------> [ Cloudflare edge ] <----------------------'
                            |
                            v
                    [ apig.unsearch.dev ]
                    Fastify 5.3 (TypeScript)
                            |
            +---------------+---------------+--------------+
            v               v               v              v
       [ Neon         [ Razorpay        [ WhatsApp     [ Twilio
         Postgres ]     Subs +            Business       fallback ]
         + Drizzle      Autopay ]         API ]
         ORM ]              |
            |               |
            v               v
        [ R2 photos ]   [ Webhook ←── back to API ]

Why this stack

• Flutter for member + trainer apps — single codebase iOS/Android/web, deploys to Cloudflare Pages for web preview
• Next.js 16 + Cloudflare Workers for admin — server-rendered, edge-fast, no server to maintain
• Fastify + TypeScript + Drizzle + Neon for API — Drizzle gives us SQL precision without ORM bloat; Neon’s serverless Postgres scales without ops; Fastify is fast enough that we don’t need to think about it
• Razorpay for payments, autopay, and subscriptions — practical default for India, with UPI Autopay support via NPCI/Razorpay rails
• WhatsApp Business API + Twilio SMS fallback — primary channel; SMS is the lifeline
• R2 for media — Cloudflare R2 has no egress fees, perfect for member photos/videos
• No Redis dependency in MVP — OTP storage falls back to in-memory (single-instance acceptable until M5+; then migrate to Upstash Redis)

Multi-tenancy

Every table has a gymId foreign key. API enforces tenant isolation at the route level (JWT carries gymId, all queries filter by it). No row-level security policies yet — application-layer isolation is simpler and audit-clear. RLS migration is a Year 2 hardening item.

White-label architecture

A “Pro” gym’s app is built from the same Flutter codebase using build flavors + Fastlane CI/CD:

1. Owner submits brand assets (logo, color, name) in admin
2. CI pipeline builds an iOS + Android APK/IPA with those assets
3. Owner provides their Apple/Google developer accounts (or we host under a parent account with their branding)
4. We submit; review takes 1-2 weeks for first apps
5. Subsequent updates are over-the-air for the Flutter side

This pipeline is the M5 dependency. Without it, Pro tier caps at the white-label-via-our-app-store-account workaround.

8. Screens we still need to design

9. Pre-existing v1 spec preserved

The deeper UX/IA spec (200+ exercise screen designs, animation strategy, muscle-overlay SVGs, video-production budget) is preserved in archive/workout-ux-spec. The technical architecture v1 (Flutter + Next.js + PostgreSQL rationale, multi-tenant RLS plans, AI/ML layer) is in archive/tech-architecture.

This refreshed PRODUCT doc is the operating reality, not the full PRD. When implementation needs deeper spec, refer to those archived docs.