Inspiration

When I was a freshman in college, balancing academics and athletics was one of the hardest things I'd ever faced. I had clear goals — compete at a higher level, improve my performance — but the path to get there was completely unclear. I didn't know how hard to train on any given day, when to rest, or how my eating and sleeping habits were actually affecting my readiness. I was making decisions based on gut feeling, and it cost me — sometimes pushing too hard and getting hurt, sometimes holding back when should have trained harder.

I looked for tools that could help, but existing fitness apps only tracked calories and steps. None of them could tell me, "Given your condition today, here's what you should do." I wished I had an app that could take my vague ambition, break it down into a structured plan, and guide my daily decisions with real data.

That's why we built Ambicore — the tool I wish I had as a freshman. A "second brain" for athletes that turns an unclear goal into daily action, grounded in sports science.

What it does

Ambicore is a Direction B (Zero-to-One Builder) solution that takes a vague athletic goal and transforms it into a structured, AI-powered execution system:

  1. Goal Clarification — AI asks personalized deepening questions about your current level, constraints, injury history, and concerns, then generates a phased training plan with explicit reasoning
  2. Daily Condition Tracking — Combines three validated metrics (EA Score from IOC REDs guidelines, Hooper Index for subjective wellbeing, and sleep) into a single Condition Score (0–100)
  3. Train-or-Rest Decision Gate — Before generating a menu, the app asks: "What do you want to do today?" When condition is critical, it actively recommends rest and requires deliberate override to proceed
  4. AI Training Menu — Generates sport-specific, phase-aware, condition-adapted menus with reasoning. Users can edit menus via natural language

How we built it

・Frontend: Next.js 14 + Tailwind CSS for a mobile-first dark-themed UI with animated SVG gauges and landscape backgrounds ・AI: Google Gemini 3.1 Flash Lite for calorie estimation (text + image), goal clarification, plan generation, and training menu generation ・Backend/Storage:** Supabase for persistent state (daily logs, condition data, plan phases) ・Condition Score Engine:** Rule-based computation combining EA (7-day moving average), Hooper Index, and sleep — deliberately not AI, because established medical formulas don't benefit from LLM inference ・AI Coding Assistance:** Claude Code (Anthropic) for development support

Challenges we ran into

・Hooper Index normalization bug — Our initial formula inverted the Hooper score: high Hooper (good condition) was lowering the Condition Score. It took multiple iterations to get all three components (EA, Hooper, Sleep) normalized in the same direction. ・Stale score persistence — Condition Scores were computed once at submission and stored in the database. When we fixed the formula, old scores didn't update. We solved this by deriving the score via useMemo from raw values instead of persisting it as independent state. ・Gemini free-tier rate limits — We hit the 20 calls/day limit on gemini-3-flash-preview during testing. We switched to gemini-3.1-flash-lite (500 RPM free tier) to keep the app functional. ・Calendar date handling — Early versions used array index to track days, causing records to shift when users skipped days. We migrated to date-keyed records (YYYY-MM-DD) for reliability.

Accomplishments that we're proud of

・The AI vs. rules distinction — We didn't just use AI everywhere. We deliberately chose rule-based computation for the Condition Score (where medical formulas exist) and AI for menu generation (where the combinatorial space is too large for rules). This principled separation became the strongest part of our architecture. ・The train-or-rest decision gate — When condition is critical, the "Train" button disappears entirely. The user must either choose rest or consciously override with a risk warning. This isn't a feature — it's the core value proposition. Everything else exists to make that one daily decision better. ・Uncertainty as a first-class UI element — Every AI calorie estimate shows "±20% margin of error." Every medical score includes a disclaimer. We treat AI outputs as decision inputs, never as answers.

What we learned

・When NOT to use AI matters as much as when to use it. We initially used AI for everything, but realized the Condition Score should be rule-based. The IOC formula is well-defined — an LLM would only add hallucination risk. This became a key insight for our responsible AI design. ・Uncertainty must be visible. Early versions displayed calorie estimates as exact numbers. Users trusted them blindly, which skewed Condition Scores. Adding the error margin changed how users interpreted the data. ・The decision moment is the product. Tracking, scoring, and menu generation are supporting features. The real value is helping the athlete make one better decision every day: train or rest.

What's next for Ambicore — AI-Powered Condition Intelligence for Athletes

Wearable integration — Connect with Apple Watch, Garmin, or Whoop to auto-capture sleep, heart rate variability, and training load instead of manual input Coach dashboard — Let coaches view their team's Condition Scores and override recommendations, adding a professional layer to the Human-in-the-Loop design Longitudinal trend analysis — Use accumulated daily data to surface patterns ("Your condition drops every Monday — are weekends affecting recovery?") and proactively adjust plans Multi-sport periodization — Support athletes training for multiple events with overlapping timelines and competing recovery demands Weight-tuning for Condition Score — Let users or coaches adjust the EA/Hooper/Sleep weighting based on their sport's priorities (e.g., endurance sports may weight EA higher)

Built With

  • claude
  • code
  • google-gemini-3.1-flash-lite-api
  • react
  • supabase-(postgresql)
  • tailwind-css
  • typescript
  • vercel
Share this project:

Updates