I have worn a WHOOP band for three months. Before that it was an Apple Watch, and I felt scattered about my health, with a nagging sense that the data I was getting was not the best data I could get. The band fixed the data. It did not fix the scattering. Every morning I still woke up to three opinions about my body. The band on my wrist had one: a recovery score, a sleep score, a number for how hard yesterday was. The scale in the bathroom had another: weight, body fat, lean mass, each with its own little arrow. The notes app on my phone had the third, which was the lifting plan I had written for myself in a hopeful mood some Sunday. None of the three had ever met. The band did not know what the scale said. The scale did not know I had played soccer with my sons until dark. The plan did not know anything at all, because it was a list.
The decision I needed every morning was small. Lift heavy today, or walk? I am forty, I have two boys who want a goalkeeper, and I have a lifting habit I want to keep for the next thirty years rather than the next thirty days. That one question is the whole reason I own any of the gear. And none of the gear could answer it, because the answer lives in all three places at once, and each app could only see its own.
So I did what I now do with most problems that look like a software problem and are really a question problem. I wrote the question down, opened Claude Code, and built the smallest thing that could hold all three answers in one place. It took a weekend, about 750 lines of code I did not write by hand, and a scale that turned out to have no front door. Here is what it looks like, what it cost to learn, and how you can do it with whatever band and scale you already own.
The thirty-second answer
✶ The thirty-second answer
The devices stay the devices. The plan lives in one place that can read all of them. That place is a small health hub: a tiny program that pulls my WHOOP data through its official API every few hours, takes the Renpho scale’s readings by a side door through Apple Health, and keeps everything in one database with nothing thrown away. Claude reads that database through a connector. A Claude Project with one job, lifting coach, reads it every morning before it answers the only question I ask: what kind of day is this?
What that buys me is one snapshot instead of three apps, one weekly write-up instead of a scroll through charts, and a coach that reasons across sleep, recovery, strain, and body composition at the same time. I still make the call. The coach makes sure I make it with everything on the table.
The problem was a decision, not a dashboard
My first instinct was wrong, and it is probably yours too. I wanted a dashboard. One beautiful page with every chart on it, the way the fitness apps imagine you want your data. I sketched it. I even asked Claude Code to start it.
Then I asked myself what I would do with the page, and the honest answer was: look at it, feel vaguely informed, and go lift whatever the list said. A chart of my HRV over six weeks is interesting the way a weather map is interesting. It does not tell me whether to bring an umbrella.
The real problem was that each app was excellent at its own number and blind to everyone else’s, and the decision I cared about needed all of them at once. A 32% recovery means one thing after eight hours of sleep and a different thing after five. A weigh-in means one thing on a lifting week and another on a week of walking. The fragmentation was never a data problem. It was a decision problem, and a decision needs its inputs in one room.
So the rule I would hand anyone starting the same project is the one I had to learn: start with the question you want answered each morning, not with the tools you own. Everything downstream gets simpler.
What I was working with
| Piece | What it knows | How it talks |
|---|---|---|
| WHOOP band | recovery, heart rate variability, resting heart rate, sleep, strain, every workout | an official API with a login flow |
| Renpho scale | weight, body fat, lean mass | no API I could use; it syncs to Apple Health on the phone |
| Claude | the reasoning, the coach, the weekly write-up | a connector into the hub |
| Claude Code | wrote every line of the hub | the sessions, not a chatbot |
You probably own a different band and a different scale. The brands do not matter. What matters is the pattern: one device with a front door, one device without, and a place in the middle that can hold both.
What the hub looks like now
The hub is a small Node program. It has five tables, one for each kind of thing: recovery, daily cycle, sleep, workout, body composition. Every row keeps a column holding the raw record exactly as the device sent it, so nothing is lost when I change my mind about what matters.
| Layer | What is there |
|---|---|
| The pull | Every three hours it asks WHOOP for the last two weeks and updates what changed. Once a day was not enough; see the lessons |
| The side door | The scale sends readings to Apple Health. An export app on the phone pushes each new reading to the hub over the internet, with a key |
| The store | One SQLite file. Five tables. A raw column on every row |
| The host | A small always-on server in the cloud, so the Mac does not need to be awake for the coach to read at 6 a.m. |
| The connector | Claude gets five questions it can ask: snapshot, recovery trend, sleep trend, workouts, body composition |
| The coach | A Claude Project whose one instruction is to reason across all five before it says anything |
| The write-up | A weekly digest the coach drafts and files in a private Notion page |
The snapshot is what I look at most. Here is this morning’s, with the shape of it intact:
Four lines. The band app shows me the first three on three different screens, and the fourth lives in a different app entirely. Four lines together is the whole product.
What a morning looks like now
I wake up, open the coach, and type one question. Usually it is “what kind of day is this?” Sometimes it is “I have soccer with the boys at five, should I still lift?”
The coach reads recovery, last night’s sleep, the strain of the last few days, and the body-composition trend, and answers in a sentence with a reason. “Green morning on the back of eight hours. Take the heavy day; they have been rare.” Or: “Thirty-four percent on five and a half hours. Technique day, keep the weight down, and nothing after the kids’ practice.”
Then I decide. Some mornings I overrule it, because the coach does not know that a friend is in town or that I need to hit something heavy for reasons that have nothing to do with recovery. The point of the loop was never an automated body. It was a better-informed human. I have more information than I did, and I use the same judgment I always had.
What a Sunday looks like
Once a week the coach writes the week up. The digest has four parts and I would keep them in this order if I were you: the week at a glance, a day-by-day table, the coaching implications, and a short list of open questions the data cannot settle.
The open questions turned out to be the best part. One week the list asked whether a single-day five-pound drop followed by an eight-pound rebound was real or whether someone else had stepped on the scale. Another week it asked why I had trained twice on a morning the band called a 19, and whether that was a choice or a standing commitment. A standing commitment is a different kind of problem than a bad decision, and the right move is to program around it instead of fighting it.
A good question from a machine is worth more than a good chart. The chart tells you something happened. The question makes you say why.
The lessons, in the order they cost me
Each of these is a problem, what I tried, and what actually worked. Several cost a day. One cost a month of bad weeks before I could see it.
Start with the decision, not the dashboard
I covered the first lesson above and I am repeating it because it is the one that saves the most time. The dashboard I almost built would have taken a week and told me nothing I act on. The four-line snapshot took an evening and I read it every day.
The scale has no front door. Go around it
The Renpho scale has an app and a cloud and no way for an ordinary person to ask it for data. I spent an evening looking for one. Then I noticed the scale already sends every reading to Apple Health on my phone, and Apple Health will hand its data to any export app that asks. So the path is scale to phone, phone to export app, export app to my hub, three hops for one number. It is ugly and it has worked since July.
The lesson is general. Almost everything you own leaks its data somewhere, and the somewhere is usually Apple Health or Google Fit or a CSV export buried in a settings menu. Look for the leak before you look for the API.
Pull often, not once
The first version asked WHOOP for new data once a day, at night. So a lift at noon did not exist until the next morning, which meant the coach was always a day behind on the thing that mattered most. Two days in, I changed the pull to every three hours. The whole change was one line and the coach got a day smarter.
Keep the raw
Every table in the hub has a column holding the raw record from the device. I added it on a whim because Claude Code suggested it. Every time I change my mind about which fields matter, the data is already there, waiting. If you remember one technical thing from this guide, remember the raw column.
Let the system doubt a reading
The five-pound overnight drop would have been a trend if I had let it. The coach flagged it as noise because it was looking at the week, not the day. A single sensor reading is a rumor. Build the thing that looks at the week.
The Mac cannot be the server
Version one ran on my laptop, which meant the coach could only read the hub when the laptop was open. At 6 a.m. it was not. So the hub moved to a small always-on server in the cloud, with the scale pushing straight to it, and the laptop went back to being a laptop. I learned the same lesson a second time with my Claude Code sessions, and wrote that one up too: the machine you carry and the machine that never stops have to be two different machines.
A secret in a URL is a password
The connector reaches the hub through an address with a long random key in it, because the connector cannot send custom headers. That is fine as long as you treat the address like a password, and I nearly did not. Before anything went live I ran a security pass with Claude Code. Anything you build in an evening is reachable from the internet in a minute. Check it before it is.
The data found the late nights
The second week of digests changed my life a little. The day-by-day table showed a night split into two blocks, an hour and a half and then five and a half, and the coach asked why. I did not know. So I asked a different system, the one that reconstructs my work hours from my Claude Code sessions, and it showed a session opened at 1:42 in the morning.
I had been telling myself the bad lifting weeks were a programming problem. They were a sleep problem, and the sleep problem was a late-night-work problem, and no app on its own could have seen across the gap. The band knew I slept badly. The work log knew I was up. Only the hub, with both in one room, could connect them. The human in the loop was the one staying up, and he needed to be told.
What changed
I will keep the results short and specific, because this is not a transformation story and I distrust the genre.
The one pattern that reliably wrecked a week got a name. Four sessions stacked on a low-recovery morning after a short night produced the deepest crash in the log, three weeks in a row. Once the digest named it, I could see it coming, and I stopped. The week it was named, the back half climbed from a 19 to a 78.
Sleep went up by about an hour a night once it had a number next to it every morning. Nothing else changed. Recovery followed, from a 19 to a 78 in four days.
I also learned what my instrument is bad at. The band undercounts lifting badly, so for a while the coach was reading my heaviest days as easy ones. We now program off recovery, HRV, and sleep, and treat the strain number as a rumor. Know what your sensor cannot see, and stop asking it.
What is still rough
The scale push has gone quiet twice. Both times nothing broke loudly. The hub just stopped receiving readings and the coach quietly worked from a two-week-old weight. The fix on my list is a staleness check: if the newest body reading is more than five days old, the coach says so before it says anything else. Silent pipes are the normal failure, and the coach should name them.
The weekly digest loop ran three Sundays and then stopped. The three digests it wrote were good enough that I want it back.
The coach is only as good as the question I ask it, and on a busy morning I ask a lazy one. A short list of better morning questions is half-written.
Nutrition is not in the hub at all. That is a second guide, and a harder one.
What I am doing next
Fold the digest’s open questions into the morning check, so the coach asks them live instead of once a week. Put a one-line health read into the dashboard I already look at every morning for my work sessions, so the body and the work show up on the same screen. And, maybe, clean the hub up enough to share as a template, because the pattern is the useful part and the code is nothing special.
Questions I get asked
Can Claude read my WHOOP data directly?
Not out of the box. WHOOP has an official API that any member can request access to, but Claude needs a connector to reach it, and I did not want the coach to depend on one device anyway. So the hub pulls from WHOOP every three hours into its own database, and the connector sits in front of the database. Claude gets five things it can ask for: a snapshot, the recovery trend, the sleep trend, the workouts, and body composition.
How do you get the Renpho scale’s data out if it has no API?
Through Apple Health. The Renpho app already writes every weigh-in to Apple Health on the phone. An export app reads Apple Health and sends each new reading to a small web endpoint on the hub, with a key. Three hops for one number, and it has run since July. Any scale that syncs to Apple Health or Google Fit can take the same path.
Do I need to know how to code?
No. I have never written code for a living. Every line of the hub was written inside a Claude Code session by asking for what I wanted in plain sentences and reading what came back until it did what I meant. The whole thing is about 750 lines. The sidebar in this guide lists the steps in the order that worked.
What does the lifting coach actually do?
It is a Claude Project with one instruction: read every source in the hub before answering, and answer the morning’s question in a sentence with a reason. I ask “what kind of day is this?” and it tells me heavy, moderate, or technique, and why, using recovery, sleep, the last few days of strain, and the body-composition trend. On Sundays it writes the week up with a day-by-day table, coaching implications, and a list of open questions the data cannot settle.
Where does the hub run, and what does it cost?
On a small always-on server in the cloud, because the coach needs to read it at 6 a.m. whether or not any laptop is open. The cost is a few dollars a month of hosting, the band’s existing membership, one export app for the phone, and a scale I already owned. The first version ran on my laptop and failed every morning the laptop was closed.
Is my health data safe doing this?
It is as safe as the care you take, which is the honest answer for any homemade system. The hub is private, the connector reaches it through an address with a long secret key, and I ran a security pass with Claude Code before anything went live. If you build one, run the same check before it is reachable from the internet, and treat the connector address like a password.
What changed once you had it?
The one pattern that reliably wrecked a week got named and stopped: stacking four sessions on a low-recovery morning after a short night. Sleep went up by about an hour a night once it had a number next to it, and recovery followed. The hub also found that a run of bad weeks traced to late-night work sessions, which no single app could see on its own. It was a sleep problem before it was a lifting problem.
— Joe
