Skip to main content
Back to case studies
product2 min read

Fit Tracker: multimodal AI in a shipped app

My role & accountability

Creator: product, development and release.

Next.js 16React 19TypeScriptTailwind CSSPrismaSupabaseClaude APIAndroid TWA

Problem

Most diet and workout apps fail because of daily logging friction: manually entering every ingredient from long food tables or structuring workout progressions demands time and discipline that most users drop within weeks.

Fit Tracker was built to remove that friction with multimodal AI — letting users log meals via photo, audio or free-form text and receive personalized workouts — without turning variable LLM API usage into unsustainable unit economics.

Constraints

  • AI unit economics: multimodal calls (especially image analysis and frontier reasoning models) carry variable per-request costs; an unlimited flat plan on the heaviest model would break product margins.
  • Mobile reach without doubling the codebase: the app needed to live both on the web and on Google Play while keeping a fast single-developer release cycle.
  • Production reliability: the platform handles user accounts, workout/nutrition history, subscriptions and payment webhooks in production.

Decision

Trade-off

Chosen

Next.js PWA wrapped with Android TWA (Bubblewrap) + user-selectable model tiers

Discarded alternative

Separate native apps (Kotlin/Swift) with a single fixed backend model

TWA eliminates duplicated UI and business logic while supporting Google Play Billing and push notifications, and exposing model tiers balances margin and latency.

Fit Tracker multimodal pipeline
  1. Input (Photo, Audio or Text)
  2. Tier Selection (Haiku / Sonnet / Opus)
  3. Claude API (Structured extraction)
  4. Prisma + Supabase persistence
  5. Web + Android TWA (Google Play)
  1. Single productive stack: full-stack Next.js 16 + React 19 + TypeScript app styled with Tailwind CSS, backed by Prisma + PostgreSQL (Supabase) and deployed on Vercel.
  2. User-selectable reasoning level: instead of hiding the underlying model, users pick the AI "thinking level" (Haiku, Sonnet or Opus via Claude API), tying model capability and cost directly to their subscription tier.
  3. Android distribution via TWA (Trusted Web Activity): packaged the PWA with Bubblewrap and integrated Google Play Billing, shipping store shortcuts and push notifications without maintaining a separate Kotlin/Swift codebase.
  4. End-to-end test coverage: Vitest (unit and integration) and Playwright (E2E) suites guarding critical flows prior to every production release.

Outcome

  • Live in production at fittracker.com.br and published on Google Play.
  • Multimodal meal logging (photo, audio, text) and personalized workout workflows operating in production.
  • Predictable per-tier unit economics connecting model selection directly to user revenue.

What I learned

  • In AI products, architecture is business model design: exposing capacity choices (Haiku/Sonnet/Opus) simultaneously manages user expectations and unit margins.
  • Distribution is as much engineering as coding: releasing via TWA involved signing keys, asset links, manifest constraints and store review flows — lessons that shape how you architect a web product from day one.
  • Automated tests unlock solo velocity: reliable integration and E2E suites make daily production shipping safe.