Health Tracker

Log a reading. See how it moves. Know whether it sits in a healthy range.

A personal health-metrics tracker built to be opened on a phone in five seconds and read properly on a laptop. No account, no server, no database — your readings live in your browser and go nowhere unless you tell them to.

Try the live demo →  ·  Deploy your own  ·  How it was built

_{The dashboard, with sample data. It follows your system theme — this screenshot does too.}

Health numbers arrive scattered and stay scattered. A lab report as a PDF in email, a blood-pressure cuff that remembers nothing, a weight you noted in a chat with yourself. Each number is meaningless alone: 34.1 ng/mL is either fine or a problem depending on which metric it is, and you have to look that up every single time.

This app does two things about that. It keeps every reading in one place, and it knows the reference range for each one — so 34.1 ng/mL shows up as Sufficient, and a chart shows you the range shaded behind the line.

Dashboard

Add a reading

A single metric

34 readings, a target line, and the window picker. Averages, highs and lows are computed for whatever window you pick.	The reference range, shaded. Three lab draws climbing out of Deficient, through Insufficient, into Sufficient — the dashed line saying there is not yet enough here to call a trend.

Three ways in, in increasing order of commitment.

1. Open the demo. health-tracker-ssd.vercel.app — add a reading and it is yours, stored in your own browser. Nothing is sent anywhere. Nobody else sees it, including me.

2. Install it. Open that link on your phone, then Share → Add to Home Screen. It becomes an app: own icon, full screen, works on the Underground.

3. Deploy your own. Below. Two minutes, free tier, and then the URL is yours rather than mine.

First run tip. Set your height in Settings once — it is what turns every weight reading into a BMI. Then pin the three or four metrics you actually care about; the dashboard reorganises itself around them.

The app is a Next.js build with no server, no database, and no required environment variables. So deploying is genuinely just this:

Or from your machine:

npx vercel

Or push your fork to GitHub and import it at vercel.com/new — every default is already correct.

Any static-friendly host works too (Netlify, Cloudflare Pages, a Raspberry Pi on your desk). There is no backend to stand up.

git clone https://github.com/sartaj1995/health-tracker.git
cd health-tracker
npm install
npm run dev

Then open http://localhost:3000.

npm run build && npm start   # production build
npm test                     # the test suite
npm run lint                 # eslint

Node 18+ is all you need. No database to migrate, no .env to fill in, no API keys — the app runs complete on a fresh clone.

357 tests over the pure logic, run with npm test and on every pull request.

They exist mainly for one reason: a wrong reference threshold does not crash anything. It quietly reports a reading as Normal when it is not, and there is no way to notice. So every clinical boundary in the catalogue is pinned by a test — HbA1c flipping to Prediabetic range at exactly 5.7, LDL to Near optimal at 100, BMI to Overweight at 23 on South-Asian cutoffs and 25 on WHO. Change a cutoff and a test goes red naming the one you moved.

The rest covers the logic that is easy to get subtly wrong: BMI drawing on one height and one weigh-in per day, dates anchored at local midday so a timezone can never shift a reading a day, and backup parsing dropping unreadable rows without failing an otherwise good restore.

By default: in your browser's localStorage, and nowhere else. No account, no analytics, no telemetry, no network request that carries a reading. This is also the honest limitation — your laptop and your phone are two separate stores that never meet.

There are two ways across.

Export / import. Settings → Export gives you a JSON or CSV file. Import the JSON on another device. Manual, but it is your data in a plain file you can read.

Google Drive backup. Optional and off until you set it up. When on, the app keeps a single file in your own Drive and re-uploads after every reading, so two devices stay in step. It uses the drive.file scope, which grants access only to files this app itself created — the rest of your Drive stays invisible to it, and because Google classes that scope as non-sensitive there is no verification review and no "unverified app" warning.

NEXT_PUBLIC_GOOGLE_CLIENT_ID=your-client-id.apps.googleusercontent.com

Every line of this app was written by Claude Code. I did not write the components, the reference ranges, the chart code, or the service worker. I described what I wanted, reviewed what came back, and said what was wrong.

That is worth stating plainly rather than burying, because it is the more interesting thing about this repository. The app is a weekend health tracker. The process is the part that might change how you work.

The whole thing was built the way you would build it with a colleague: one branch per change, one pull request each, reviewed before merge.

The details I would have got wrong, or never thought about, in a weekend project:

• Dates are parsed at local midday, so a timezone shift can never slide a reading into the previous day. There is a one-line comment in lib/stats.ts explaining exactly that.
• Storage sits behind a HealthRepo interface in lib/storage.ts. localStorage is one implementation; pointing it at an API route later is a new implementation and zero page changes. That seam is why Drive backup landed as an additive PR.
• Corrupt or unavailable storage starts clean instead of crashing — private mode, blown quota, a half-written JSON blob.
• Three readings do not get a trend line. The chart goes dashed and says why.

• It shipped metric labels through a title-case helper, which turned LDL into Ldl and HbA1c into Hba1c. Correct-looking code, wrong for this domain. Fixed in #4.
• The dashboard was a flat list that grew every time a metric was added, until it was unreadable at 26. Giving it a hierarchy — worth a closer look, pinned, everything else — took an explicit instruction. The agent will keep adding to a structure long after the structure has stopped working.
• The redesign only became coherent once it had a design system to work against, rather than "make it look better". The skills it used are committed in .claude/skills/ so the visual language is reproducible rather than a lucky roll.
• It stored height as a dated series, so re-measuring could never rewrite an old BMI. Careful work, and wrong for the people using it: adult height barely moves, and once any height reading existed the height in Settings was silently ignored, so the value you could see was not the value in use. Height is one number in Settings now.

You do not need this repository. You need a clear description of what you want and the willingness to reject the first answer. What made the difference here:

1. Say what the thing is for, not what to build. "Opened on a phone in five seconds, read properly on a laptop" shaped more decisions than any component spec would have.
2. One change, one branch, one PR. It keeps each diff small enough to actually read, and a bad direction costs you one branch instead of an afternoon.
3. Review the domain logic, not the syntax. The code compiles. What needs your eyes is whether LDL is spelled right and whether the BMI maths is defensible.
4. Commit your skills and config. .claude/ is in this repo, so the next session starts where the last one ended.

flowchart LR
    UI["Pages & components<br/><i>Next.js App Router</i>"]
    Store["Store<br/><i>React context</i>"]
    Repo["HealthRepo<br/><i>interface</i>"]
    LS[("localStorage")]
    Drive[("Your Google Drive<br/>one file, drive.file scope")]

    UI <--> Store
    Store <--> Repo
    Repo <--> LS
    Store -.->|"optional, off by default"| Drive

    style Drive stroke-dasharray: 4 4

About 4,100 lines of TypeScript, no state library, no component library, no backend.