Product vision

What FitKit is

FitKit is an API-first fitness operations platform for small-to-medium fitness businesses. One platform covers three jobs that today require five tools each: running the business (memberships, billing, debt), growing the people (leads, CRM, messaging, community), and delivering the training (programming, scheduling, results, goals).

The product is currently a web app (Next.js) on top of a NestJS API. The API is the contract; the web app is the first client. The roadmap explicitly adds more clients — WhatsApp first, then native mobile — on the same API surface.

Target market

Primary: Israeli boutique fitness studios and independent coaches.

• CrossFit boxes, HIIT studios, yoga/Pilates studios, martial arts dojos, online coaches, personal trainers.
• Sizes: 20–300 members. Single location is the dominant case (multi-location is explicitly deferred — see roadmap.md).
• Geography: Israel first (Hebrew RTL, local payment gateways, WhatsApp culture). Mediterranean / EU later.

Three operator personas the product is designed around (full detail in personas.md):

• Studio Shira — owns a physical studio, 80–200 members, today pays Arbox or Wodify ₪600–1,200/mo.
• Online Yotam — online coach with 40+ remote clients, today uses TrueCoach or Trainerize plus WhatsApp and Sheets.
• Personal Danny — independent PT, 15–25 clients, today uses Notion + WhatsApp + ad-hoc invoicing.

These three share ~70% of the platform (members, payments, programming, messaging, analytics) and diverge ~30% (class booking for Shira, async program delivery for Yotam, deep 1:1 profiles for Danny). The product treats this as one platform with persona-aware defaults — not three products.

Why FitKit exists (differentiation)

The Israeli SMB fitness market is served by two camps:

1. Studio-incumbent software (Arbox, Wodify, Mindbody). Feature-rich, but expensive (₪600+/mo), dated UX, studios-only — ignores online coaches and personal trainers entirely.
2. Coaching-niche tools (TrueCoach, Trainerize, TrainHeroic). Modern UX, but no real business management — no native billing, no CRM, no class scheduling.

Everyone else lives in Notion + WhatsApp + spreadsheets.

FitKit’s wedge:

The marketing positioning lives at apps/marketing/ (an Astro site, separate deploy). This doc is the engineering-facing version of the same idea.

Hebrew / RTL as a first-class concern

Default locale is he (see apps/web/src/i18n/config.ts). Hebrew is right-to-left; en/ru are left-to-right. Every Radix overlay, every form, every layout has to render correctly mirrored. The codebase enforces:

• No hardcoded English strings. All user-facing text comes from apps/web/src/i18n/dictionaries/{en,he,ru}.json. New keys land in all three dictionaries in the same PR.
• API returns data, not labels. Translation is web-side only, which keeps the API contract small and makes future non-web clients (WhatsApp, native) trivial to localize.
• RTL-aware components. Tailwind v4 logical properties (ms-*, me-*, start-*, end-*) rather than ml-*/mr-*. shadcn/ui base components handle this; custom components must follow suit.

See architecture/i18n.md for the mechanics.

API-first / multi-client vision

Today’s deployment is one client: the Next.js web app at apps/web. The architecture deliberately treats this as just-one-of-many:

• All business logic lives in apps/api (NestJS). The web app calls REST endpoints via serverFetch (server components) or useApi (client components). Both auto-attach a Clerk bearer.
• Responses wrap data in { data: T } and carry explicit state fields (enums beat booleans beat client-side inference). This lets non-web clients render the same state without re-deriving it.
• Auth is Clerk on both sides. A future native app gets a Clerk SDK; a future WhatsApp bot gets a server-to-server Clerk token plus a phone-number lookup.

Planned additional clients (see roadmap.md for status):

The platform-tier model

Pricing and feature gating run on platform tiers (lite, pro, elite — see libs/db/src/lib/schema/enums.ts: platformTier). Each organization has a platform_tier column. Feature flags map tier → entitlement in libs/shared/src/lib/constants/platform-tiers.ts. Server-side enforcement runs in the PlatformTierGuard (apps/api/src/platform-tiers/platform-tier.guard.ts) via the @RequiresFeature(...) decorator. Client-side soft-gating uses apps/web/src/components/feature-gate.tsx.

Public pricing (per the product-direction doc, subject to change):

• Lite — free tier, intentional acquisition channel.
• Pro — ~₪249/mo, the default paid tier.
• Elite — ~₪499/mo, multi-location-ready and reporting-heavy.

The roadmap calls out specifics like “WOD tracking is Pro+”, “Analytics dashboard is Pro+”, etc. Treat the tier matrix in _archive/product/fitkit-product-roadmap.md as illustrative — the source of truth is libs/shared/src/lib/constants/platform-tiers.ts.

What FitKit is not

• Not an enterprise gym chain platform. That’s Mindbody’s turf; the database and UX are not built for 50+ locations.
• Not a workout-programming-only product. TrainHeroic and TrueCoach do that better.
• Not a nutrition coaching product. Adjacent but explicitly out of scope.
• Not a WhatsApp replacement. It integrates with WhatsApp for transactional flows (booking confirms, payment reminders, the future bot). It does not try to replace personal coach↔member conversations on WhatsApp.

Where the rest of the docs go from here

• personas.md — who actually uses this and what blocks them today.
• glossary.md — the domain vocabulary (Plan vs Subscription, Class Type vs Session, Form Template vs Instance, etc.).
• roadmap.md — what’s shipped, what’s mid-flight, what’s next.
• ../architecture/overview.md — the system map.