How it's built · an agentic project ·
July 2026

A personal fitness dashboard, built and run by an AI agent

Six controls make this dashboard something you don't have to supervise: it synchronizes on its own schedule, verifies its own health after every release, and surfaces a stale reading before anyone has to ask why the numbers look wrong. Apply them in sequence, though each stands as its own safeguard if you stop partway. The same architecture governs any wearable with an API, not only WHOOP: Oura, Garmin, Apple Health.

• 01 Tools & governance
• 02 Connect the data
• 03 Sync efficiently
• 04 Publish, don't depend
• 05 Health check
• 06 Ordinary infrastructure
• Field notes

01Choose the right tool for each task, and calibrate the model to the stakes

Four modes serve four distinct functions, each with its own role in how the system is governed. Chat is where decisions get made: which metrics matter, how a daily recommendation should be phrased, drafting a page like this one. The terminal (Claude Code) is where the system gets built: the sync fix, the test suite, and the smoke test were all written there, session by session, with every deploy reviewed before release. Cowork is where the system is maintained day to day: it operates directly on files and a browser, and produced this very page without a terminal ever opening. Scheduled tasks handle anything that warrants monitoring without a person asking for it: a standing check for a public pro-athlete WHOOP dataset became today's pro-athlete snapshot once WHOOP published one.

The mode determines where the work happens. A separate judgment governs how much AI capability that work warrants: routine, unsupervised tasks — like the post-deploy smoke test — run on a fast, low-cost tier; ordinary building work runs on a standard tier; the hardest problems, where getting it wrong is costly, get the most capable tier available; and writing meant for a real audience, like this page, gets a tier suited to prose. Matching the tool to the stakes keeps cost proportional to what each task actually needs, rather than running everything at the most expensive setting by default.

02Connect the data, and keep the login out of the browser's reach

Signing in to WHOOP happens once, handled entirely by a small piece of code that runs on the server — never inside the browser. That code manages every data request after that, so the actual login credentials are never exposed to anything running in a browser tab. This is the one control worth enforcing without exception, regardless of which wearable's data is being connected.

03Keep syncing fast, and don't let a login refresh collide with it

An early version of this sync pulled data in close to 180 small requests each time it refreshed — slow enough that it occasionally dropped the connection mid-sync. Two fixes resolved it: batching those requests down to roughly 8, and making sure the login was confirmed valid before firing the rest all at once, so a login quietly expiring mid-sync couldn't corrupt the update.

04Publish a snapshot; don't make visitors dependent on a live call

Visitors never query WHOOP directly. A small storage layer holds the most recently published reading, and that is the only source the page reads from. If a sync fails or a credential needs attention, visitors still see the last verified reading, clearly labeled with its age, rather than a broken page. Refreshing that reading on demand doesn't require authentication either: a plain Refresh control on the page triggers the same pull, throttled server-side so repeated requests cannot exhaust the API's rate limit. One open gap: there is no dated history of prior snapshots, so a genuinely corrupted sync could still overwrite the one verified copy with nothing to restore from.

05Build a health check that only observes

The check that runs after every deploy confirms the live data pipeline is actually healthy and current, not merely that the deploy completed. It has no authority to remediate anything, only to report clearly when something is wrong. This is the control the 21-day gap described above was missing: a failed sync went undetected because the system was verifying the output, not the pipeline producing it.

06Keep the infrastructure unremarkable

The code resides in an ordinary GitHub repository; pushing to it constitutes the entire deployment process, and Netlify rebuilds in under a minute. Small pieces of server-side code handle the WHOOP sign-in and the sync itself; a small storage layer holds the snapshot visitors actually see. One control worth noting: the site skips a full rebuild entirely when a change only touches internal notes or scripts, not anything a visitor sees — since Netlify's free tier meters how many rebuilds are allowed, and a personal project shouldn't spend them on changes nobody will notice.

Field notes

What governing this system required

Verify the evidence before trusting a theory. The syncing timing bug from step 03 looked like something else twice over: a missing permission, then a login that wasn't saving properly between sessions. The actual cause only turned up once the code itself was examined closely, not guessed at from the symptoms.

Treat login credentials as something only a person controls, never something that passes through a chat conversation. Any credential exposed even once gets replaced immediately, never reused — generated and rotated directly in WHOOP's own account settings.

Compare only what both sides actually measure. The pro-athlete snapshot sets resting heart rate and weekly sessions side by side because this dashboard tracks both; everything else is shown as context, never forced into an unsupported comparison.