# How to build a fitness app with AI you actually own

> Workouts, progress, and agent docs in a fitness product repo you keep — a how-to-build guide, not a sandboxed-generator credit comparison.
> By Dave · 2026-09-11
> Source: https://otf-kit.dev/blog/how-to-build-a-fitness-app-with-ai

Prompt-to-app generators are excellent at one job: turn "build me a workout tracker" into a clickable preview without asking anyone to own a product repository. That loop is real for a weekend prototype.

It is the wrong system of record when the fitness app *is* the product. Members need workouts, progress, and profiles inside software you brand, deploy, and keep changing. Renting a generator forever leaves those surfaces on a vendor host — and leaves Cursor or Claude Code without project memory beside the screens.

The fitness-kit answers that narrower job. You already use a filesystem agent. You need a fitness product as ordinary source agents can extend. This post is a how-to for that build order: workouts, then progress, then profiles you keep, then agents. It is not a generator-credits comparison (that related note lives at [otf-vs-rork](/blog/otf-vs-rork)). It is also not the [one codebase, three platforms](/blog/one-codebase-three-platforms) essay. This one is how to build the fitness product.

## What the kit actually ships for fitness work

OTF lists the Fitness & Wellness Kit on [https://otf-kit.dev/templates/fitness-kit](https://otf-kit.dev/templates/fitness-kit) and in the kit table on [https://otf-kit.dev/docs/templates/overview](https://otf-kit.dev/docs/templates/overview). Standalone price is $99; also in the Everything Bundle on [https://otf-kit.dev/pricing](https://otf-kit.dev/pricing). Live proof before checkout: [https://fitness-preview.otf-kit.dev](https://fitness-preview.otf-kit.dev). Kit docs: [https://otf-kit.dev/docs/templates/fitness-kit](https://otf-kit.dev/docs/templates/fitness-kit).

Public product claims that matter for a fitness product:

- 12 screens: welcome, login, signup, summary (activity rings plus a metric grid and recent workouts), ring detail, metric detail, workout list, live start, completed-workout detail, sharing, goal, and profile
- Reusable blocks: activity rings, week strip, big stepper, metric card, segmented control, mini bar chart
- Data plane: six app tables — `userPublic`, `dailyGoal`, `workoutType`, `workout`, `award`, `friendship` — plus auth session tables
- Agent handoff: `CLAUDE.md`, `.cursorrules`, and 20+ tested prompts under `ai/prompts/` (`add-workout-type`, `change-ring-targets`, `add-weight-tracking`, `add-food-log`, `add-screen`, `add-entity`)
- Delivery: commercial source after purchase; web deploy script in the kit docs; native binaries via the included build profiles

Purchase path: Stripe checkout, license email with a private GitHub invite, then clone and run locally (accept, invite, clone, install, run, deploy per templates overview).

## Owned fitness app versus a rented generator

Stay on a hosted generator when the primary object is a disposable preview, a vendor-hosted URL is acceptable, and those screens do not need to live in Git. Prefer an owned fitness product when most of these flip true:

- Members log workouts, see progress, and edit profiles inside *your* app
- Workout types, daily goals, and awards live in schema you can migrate
- Rings and trends are product screens, not widgets parked on a host
- Maintenance happens in Cursor or Claude Code on disk, with project memory that survives the next tool switch
- The live URL serves your clone, not a generator project

![Decision map: owned fitness product versus a rented generator](https://cdn.otf-kit.dev/blog/how-to-build-a-fitness-app-with-ai/inbody-01-decision-20260911b.jpg)

Generators remain useful. Many teams keep a hosted preview for a weekend spike while the member-facing fitness product remains the kit. Buy the kit when workouts, progress, and profiles belong in a repository you keep — same ownership thesis as [how to build an admin panel with AI you actually own](/blog/how-to-build-an-admin-panel-with-ai), applied to wellness instead of ops tables. This how-to assumes you already chose "own the app."

## Workouts first, then progress, then profiles

Anthropic's [Claude Code memory docs](https://docs.anthropic.com/en/docs/claude-code/memory) state the constraint plainly: each session starts fresh, and project `CLAUDE.md` files carry persistent architecture and conventions. OTF's [AI tool overview](https://otf-kit.dev/docs/ai-tools/overview) documents the same pattern: every kit ships `CLAUDE.md`, `.cursorrules`, and companion agent files so opening the repo does not require re-explaining the stack.

For a fitness app, that handoff starts at **workouts**, not a ring animation. A progress chart without a workout log is a screenshot. The kit already has the seams: `workoutType` and `workout` tables; list, live start, and completed-detail screens; hooks such as `useWorkouts`, `useCreateWorkout`, and `useWorkoutTypes`. Seed is deterministic after `bun run db:seed` (one demo user, three friends, eight workout types, about thirty workouts, five awards). Demo login: `demo@otf-kit.dev`. Do not invent a second workout log in chat.

```text
fitness-kit/
  app/(home)/workout/   # list, live start, completed detail
  app/(home)/summary.tsx
  app/(home)/ring-detail.tsx
  app/(home)/metric-detail.tsx
  app/(home)/goal.tsx
  app/(home)/profile.tsx
  app/(home)/sharing.tsx
  hooks/                # useWorkouts, useWorkoutTypes, useTrends, useAwards
  server/routes/        # workouts, workout-types, trends, awards, activity-feed
  server/db/            # schema, migrate, seed
  CLAUDE.md
  .cursorrules
  ai/prompts/           # add-workout-type, change-ring-targets, add-entity
  docs/
  README.md
```

Treat `ai/prompts/` as recipes for bounded jobs — add a workout type, swap ring colors, add a screen — not a license to redesign the domain from a blank chat. The free SDK at [https://github.com/otf-kit/sdk](https://github.com/otf-kit/sdk) is the shared component layer; the paid kit is the finished fitness product plus agent configs that keep the next session honest.

Once workouts resolve, members live in progress. Kit docs and the live demo show activity rings on Summary, a week strip plus giant ring on ring detail, day/week/month/year metric detail, and a big stepper for the daily move goal. Theme tokens centralize ring colors in `lib/theme.ts` so a `swap-ring-colors` prompt cannot scatter hex across twenty files. Extension rule: keep rings, goals, and trends on the existing tables (`dailyGoal`, `workout`, `award`). Paste `add-workout-type.md` or `change-ring-targets.md`, replace placeholders, and review the diff.

Profiles close the member loop. The kit ships a Profile tab (avatar, all-time stats, settings, sign out) and a Sharing sub-screen (awards plus friends' activity feed) on `userPublic`, `award`, and `friendship`. Kit docs for v1 call out that the sharing feed is mock data — real friend connections and push notifications are out of scope. If you need weight tracking or a food log, the recipe library already has `add-weight-tracking.md` and `add-food-log.md`. Do not fake a social graph only in the UI.

## Handoff: workouts to progress to agents to ship

The loop you own has four steps: workouts, progress (including profile stats), agents extending the tree, then ship on a host you control.

![Handoff map: workouts to progress to agents to ship](https://cdn.otf-kit.dev/blog/how-to-build-a-fitness-app-with-ai/inbody-02-handoff-20260911b.jpg)

1. **Workouts** — open the workout list, live start, and type chips. Confirm `workoutType` / `workout` before adding a parallel log.
2. **Progress** — extend rings, goals, and metric detail with the existing blocks. Keep ring colors on theme tokens. Profile stats and awards stay on the same schema.
3. **Agents** — every later change starts from `CLAUDE.md` and `ai/prompts/`. Prefer `add-workout-type`, `add-screen`, or `add-entity` over a blank "rebuild a fitness app" prompt.
4. **Ship** — the live URL should serve your clone. Native store binaries are a sibling concern; see [one codebase, three platforms](/blog/one-codebase-three-platforms) when you need that ship path, not as the reason you bought the kit.

## A concrete first session after purchase

After you accept the GitHub invite from checkout, the first hour should look boring on purpose. Templates overview documents clone, install, and local run. Kit docs document generate, migrate, and seed before demo data is live. Required env includes `DATABASE_URL` plus the documented auth secrets on [https://otf-kit.dev/docs/templates/fitness-kit](https://otf-kit.dev/docs/templates/fitness-kit).

```bash
git clone <your-private-fitness-kit-repo>
cd <fitness-kit>
bun install
cp .env.example .env
# fill DATABASE_URL and the documented auth secrets
docker compose up postgres -d
bun run db:generate
bun run db:migrate
bun run db:seed
bun dev
```

Open the repo in Cursor or Claude Code. Do not start with a blank "rebuild a fitness app from scratch" prompt. Point the agent at the shipped docs:

```text
Read CLAUDE.md and ai/prompts/. Then:
1) Keep workouts on workoutType + workout — do not invent a second log
2) For a new type, use add-workout-type (seed row, then chips)
3) Keep rings and goals on lib/theme.ts tokens and dailyGoal
4) For weight tracking or a food log, use the named recipe; do not fake progress only in the UI
5) Do not bypass schema → route → hook → screen order
```

That prompt works because the kit already names the hard seams. When local preview matches — inspect [https://fitness-preview.otf-kit.dev](https://fitness-preview.otf-kit.dev) first if you have not bought yet — follow the README deploy section (`bash scripts/deploy-railway.sh`). The live URL should serve your repository; the next workout type or goal change is another agent session on the same tree.

## What "you actually own" means for fitness

Ownership here is operational: workout types, logs, goals, awards, and profile rows live in Git and Postgres under your org; `CLAUDE.md`, `.cursorrules`, and `ai/prompts/` reload every session; new features follow schema → route → hook → screen; commercial rights are a one-time kit purchase (the Bundle includes fitness-kit — confirm on [https://otf-kit.dev/pricing](https://otf-kit.dev/pricing)); and swapping Cursor for Claude Code does not require rebuilding project memory in a vendor UI.

Compare that to the rented-generator loop: prompt a workout UI, share a hosted preview, then hope export stays enough when fitness must be the product. The kit inverts the order — schema, screens, and prompts arrive first; agents edit second.

fitness-kit is the wellness product lane — not a $9 landing template, and not the booking or saas-dashboard kits. For phone-and-web from one tree, see [https://otf-kit.dev/blog/one-codebase-three-platforms](https://otf-kit.dev/blog/one-codebase-three-platforms). If you already need owned workouts, progress, and profiles in a repo agents can extend, start on [https://otf-kit.dev/templates/fitness-kit](https://otf-kit.dev/templates/fitness-kit), open the live demo, and buy when the screen set matches.

## Sources

Fitness & Wellness Kit product page: https://otf-kit.dev/templates/fitness-kit

Fitness & Wellness Kit docs: https://otf-kit.dev/docs/templates/fitness-kit

Templates overview: https://otf-kit.dev/docs/templates/overview

Pricing: https://otf-kit.dev/pricing

AI tool integration: https://otf-kit.dev/docs/ai-tools/overview

Anthropic Claude Code memory: https://docs.anthropic.com/en/docs/claude-code/memory

Related (not this thesis): https://otf-kit.dev/blog/otf-vs-rork

Related ship path (phone and web from one tree): https://otf-kit.dev/blog/one-codebase-three-platforms

Live demo: https://fitness-preview.otf-kit.dev

OTF free SDK: https://github.com/otf-kit/sdk

OTF site: https://otf-kit.dev