DECK sankettambare.in/training · built with Claude Code

Ten set out.

How a page of Strava activities became a story you can walk: one day, eleven prompts, nine commits, a Strava API that went behind a paywall, a bulk export instead, and ten stick figures who walk every activity's terrain.

This is the story of one page, sankettambare dot in slash training, and how it was built in a single day with Claude Code. It began as a plan to pull everything from the Strava API. That plan hit a paywall within the hour. What shipped instead reads Strava's own bulk export, and turns three hundred and fifty-eight activities into a story: a night map of light, a spiral of days, and ten stick figures who walk the terrain of any day you pick. We'll follow those ten through the whole build, one staying behind at every turn that mattered.

02 The day at a glance 3 Nov 2026 · IST

Eleven prompts. Nine commits. One ridge.

Every pin is a prompt you typed; every square is a commit Claude pushed. Click a pin to read it.

Here's the whole day on one line. The pins are the eleven prompts, starting at five forty-eight in the morning and ending at six minutes past one, with this deck. The squares are the nine commits, about twelve thousand lines in all. Notice the rhythm: a prompt, a burst of work, a commit, then a pause where you looked at what came back and decided what it needed next. That pause is where most of the good ideas came from.

The first prompt arrived at five forty-eight. Import all the activity data from the Strava API, into its own table, with a dedicated page. No photos, everything else. And crucially: research the API first, and ask questions before building. That instruction shaped the whole day. The site already had a template for this kind of thing, the videos page synced from YouTube, so the real work was deciding what "all the data" meant.

04 Research 05:48 – 05:53

Three depths, one rate limit, four questions.

Research found three depths of data. The summary list, the detail of each activity, and the per-second streams. Each level costs API calls, and Strava allows a thousand a day, so a deep backfill takes two days. Then came five questions, each with a recommended option and the trade-off spelled out. You chose summary plus detail, store everything but show only public activities, a sync button plus a nightly job, and every connection into the rest of the site.

05 Version one 06:16 · 3842c04 · 57 files · +3,886

A whole feature, built on the API, in 28 minutes.

The first version landed at sixteen past six. Fifty-seven files: five tables with row-level security, an OAuth script with token rotation, an owner-only sync endpoint that watches Strava's rate-limit headers, the page with its list, heatmap, records and routes, and every integration you'd asked for. The site's own rules came along too: every new route needs a share card, meta tags and an SEO entry, so those landed in the same commit. You applied the schema on production straight away.

Thirty-seven minutes in, the real constraint showed up: Strava's API had gone behind a paid subscription. Could the bulk export do the job instead? It could, and in one way it did it better. The export loses kudos, segment efforts and live sync, but it carries every original FIT file from the watch, with per-second heart rate, cadence and power that the API's detail level never returned. The pivot was a clean one: the API code was deleted rather than left switched off, so nothing half-used stayed behind.

07 The import 0039 · 0040 · scripts/strava-import.mjs

From a zip to two tables, never the same row twice.

# the whole import, re-runnable
npm run strava:import -- --dir=tmp/strava-export
#  358 activities · 355 .fit · 3 .gpx
#  first run: 358 new
#  every run after: 0 new, 358 updated

The import is six stages. Unzip into a temporary folder that git ignores, so raw data never reaches the repository. Parse the FIT files, and the few GPX ones. Compute what the export doesn't contain: splits, laps, best efforts and personal-record ranks, all from the GPS track. Then the duplicates rule you asked for: upsert on Strava's id, and also skip any other file that starts within sixty seconds in the same sport. Existing rows are re-sent without their name, so a generated "Morning Run" never replaces a title you wrote. Run it ten times and you get the same three hundred and fifty-eight rows.

The export carries a risk the API hid: raw GPS without Strava's privacy zones, so every activity begins at a front door. The rule here is privacy by table, not by column. Raw tracks, start and end points, the private note and body weight live in a table only the owner can read. The public row gets a route with four hundred metres trimmed off each end, and the per-second profile that powers the stick figures stores no positions at all.

09 Design 06:49 · 0de7770 · 39 files · +3,556

"Be as creative as possible."

At ten to seven came the design brief, twice, in capitals. Redesign completely, animate it in atlas mode, enrich the classic layout, and make it the kind of page people stay on. The key move was building on sample data: a seeded, realistic log, clearly labelled, so the design could go ahead before a single real activity had been imported. It disappears on its own once the table has rows. Both layouts read the same data hook and the same filters, and the sport colours were validated as a set before any chart used them.

10 Atlas mode · the story

A story you scroll, chapters that play once.

Also in the atlas: weekly tides, a medal case, milestones, a departures board and the full log. Each chapter animates once, on first view (useInView), then belongs to the reader: scrubbers, play/pause, filters. prefers-reduced-motion skips straight to the end state.

Atlas mode is the story version. It opens on an odometer rolling up the kilometres, then paints every route on a dark map as light, oldest first. Then a spiral with one turn per year, a race against your own past best efforts, a dial of the hours you start at, weekly tides, a medal case and a departures board. Every chapter plays once when you first reach it, then hands the controls to the reader. Readers who ask for less motion get the finished picture straight away.

11 Classic mode · the reference

Six tabs for people who came to look something up.

Tabs are URL state (?tab=, never ?view=, which belongs to the shell), so every view is a link you can share.

Classic mode is for the reader who came to look something up. Six tabs: an overview with a year-against-year race line, a searchable log, a calendar where every day can be clicked, the facts, stats and personal records, and a grid of routes. The tab lives in the URL, so any view can be shared. The two layouts never compute a number differently, because both read one data hook.

At eight fifty-one the real export arrived, and it didn't match the documentation: no activities CSV at all, just the FIT files and three GPX files. So the importer gained a files-only mode, reading the summary from each FIT session and naming activities the way Strava would. You added the database key as a secret, and the first run wrote three hundred and fifty-eight activities: a hundred and seventy-eight walks, eighty-six runs, sixty-two strength sessions and thirty-one hikes. Every run since has found nothing new to add.

13 The gap

The page showed a dozen fields. The files held fifty.

Once real data was in, the gap was obvious. The page used a dozen summary fields, but the files held about fifty variables across more than a million per-second records: heart rate, cadence, power, stride length, ground contact, even the sets and reps of strength sessions. The first pass parsed all of that to work out the splits, and then threw it away. The next two prompts were about using it.

14 The reference 09:08 · 4fc9009 · +762

A chart with hikers on it, and a better idea of a day.

At eight minutes past nine you shared a reference: a growth chart with tiny hikers climbing its line. The idea it unlocked was simple. An activity is a walk along its own terrain. So each day became its elevation drawn as a line, with figures standing at the moments that mattered: the start, the fastest kilometre, the longest stop, the biggest climb, the heart-rate peak, and the finish. Each figure's stride comes from that kilometre's pace, and a long stop sits them down by a campfire.

15 Ten set out 09:16 · f908c4b · 21 files · +945

Ten set out together. One stays at every moment.

Eight minutes later came the prompt that gave this deck its name. Animate the figures. Let them rise with the line as it draws. Start with a group of ten, have a few stay along the way, and at the end have them spread out. The drawing on this slide follows the page's rule: the terrain draws itself on the activity's own clock, the group walks at its tip, and one figure stays at each moment. Once the moments are covered, each remaining figure goes wherever is furthest from the others, so the ten finish spread across the whole ridge. The same prompt asked that the whole file be used, so a new column, profile, now carries the per-second streams, with no positions in it.

16 Use everything

Every kilometre gets its own row of numbers.

Streams, thinned

1.16 M records become ~240 samples per activity: HR, speed, cadence, altitude, power, step, contact, bounce. Enough for a curve, light enough for the page.

Sessions without splits

Strength and yoga get SessionStory: heart rate over time plus the set blocks, instead of an empty terrain.

On the main page too

DayPicker puts the story in the Overview and the atlas, with chips for the latest, the longest, the latest hike and the latest session, and under any calendar day.

"Make sure you have used everything" meant going back through the file. Each activity's per-second streams are thinned to about two hundred and forty samples, which is plenty for a smooth curve and light enough to load. The splits table grew columns for cadence, power, stride, ground contact and bounce. Strength and yoga sessions, which have no kilometres, got their own story: heart rate across the session with the sets marked on it. And the day story moved onto the main page, with quick picks for the latest, the longest, and any day on the calendar.

17 Facts 09:36 · 0e0f712 · +886

44 variables. 34 facts. And where they lie.

09:36Show all the possible data variables and interesting facts derived from it

• deepStatsOf() at import boils each activity's seconds down to ~10 numbers in extra._stats: HR in 10-bpm bins, drift on runs of 8 km+, negative split, peaks, steps. No new migration.
• VARIABLES lists every kept field with its source and its coverage ("cadence: 263 of 358").
• 1,515,160 steps · 6 am · Sunday carries 38% of the km · 153-day streak · 157 spm · 1.78× Everest.

Honest about the data

Zones are measured against the 98th percentile of maxima (182 bpm), not one 195 bpm spike. A 49 km/h GPS jump is not shown as "top speed". Wrist temperature reads high, and the page says so. Three 2024 GPX runs don't stretch "longest break" to 525 days.

The next prompt asked for everything: every variable, and every fact you could draw from it. The per-second facts, like time in heart-rate zones, heart-rate drift on long runs and total steps, are computed once at import and stored as a few numbers per activity, so the page never loads the streams. The result is forty-four variables, each with how many activities record it, and thirty-four facts. Just as important was what got left out. One heart-rate spike of a hundred and ninety-five isn't treated as the true maximum, and a GPS glitch at forty-nine kilometres an hour isn't presented as a top speed.

18 Learnings

What broke, and the one-line reason why.

Some things broke along the way, and each had a one-line cause. The hike page crashed because an animation timestamp can come before the start time, so time went negative. Routes drew in with gaps because of how dashed strokes scale. The night map was too small because a few distant treks set the frame. Hikers sat by campfires on almost every kilometre. On a wide screen, all ten figures bunched up at the start. Every one of these turned up in a screenshot taken after a change, which is why each change ended with one.

19 The film 12:13 · 20fae90 · 31 files · +2,548

Sixty seconds, vertical, made from the same numbers.

12:13Now, I want to create a dynamic video which explains all the features of this new page. This should be 60 seconds vertical video. Make sure you are using remotion for creating video. Use animations and all in motion effects in video. Make sure you are creating best video with best story narration. Add that video on page as well

Datadata.mjs reads the public table through the page's own modules (Vite SSR).

VoiceEach scene's line spoken by Piper en_GB-cori-high, then measured.

ScoreSynthesised sample by sample to the scene cuts; nothing to license.

Remotion1080×1920 @ 30 fps; every motion a function of the frame.

Just after noon came the film: sixty seconds, vertical, made with Remotion, and placed on the page. The pipeline has four steps. The data step reads the public table through the page's own code, so the film can never disagree with the page. Each scene's line is spoken and measured first. A synthesised score is cut to the scene boundaries. Then Remotion renders every frame from the frame number, never from a clock. The eight scenes go from a heartbeat to an invitation, with the group of ten at thirty-one seconds.

20 Film learnings

Let the voice set the clock.

Remotion is free for individuals; a company of more than three people needs its company licence. That's noted in docs/strava.md.

The film taught its own lessons. The narration sets the clock: every line is spoken first, and each scene is sized around its line, so the film lands on exactly sixty seconds. Numbers are spoken as words, because the voice stumbled over digits. The fact cards wait for their sentences instead of racing ahead of them. Captions break at sentence ends, not at every comma. And in Remotion, everything moves by frame number. On the page, the film costs nothing until someone presses play.

21 Shipping

Checks every push. Live on merge.

• Before every push: 816 Jest tests, ESLint, a Vite build, and Playwright screenshots at desktop and phone width with zero console errors.
• The database moved first: you ran 0038, 0039 and 0040 on production as each landed. Code reads new columns only once they exist (the importer probes for profile).
• Every push deployed a preview on Cloudflare Pages, so each change was checked on real data before it reached anyone.
• Production: personal-site#69 merged on 3 Nov 2026 (118 files, 9 commits), and the page went live at sankettambare.in/training.

After every new export

npm run strava:import -- --dir=tmp/strava-export
npm run og:fallbacks -- --only=training
npm run ask:index
npm run training:film -- --publish

Shipping followed one routine. Before every push: eight hundred and sixteen tests, the linter, a full build, and screenshots at desktop and phone size with no console errors. The database always moved first. You ran each migration on production as soon as it landed, and the code was written so it never reads a column before that column exists. Every push deployed a preview of the branch, so each change was checked on real data first. Then pull request sixty-nine was merged, and the page went live. After each new Strava export, four commands bring everything up to date.

22 This deck 13:06

The tenth figure plants the flag.

The last prompt asked for this deck, built from the whole process, up to and including making it. Your prompts and answers were taken word for word from the session log, the commits from git, and the screens and recordings were captured from the live preview. The stick figures are drawn from the same joint table the page uses, and the narration you're hearing is the film's voice. If you want to reuse the approach, it fits in six lines. Ask before you build. Design on labelled sample data. Let the real data redesign it. Show a reference image instead of describing one. Screenshot every change. And put tests on the things that are easiest to lose. Ten set out together this morning, and now they're spread along the whole ridge.