If you use Technogym equipment at your gym, you've probably opened their app, tapped around a few screens, and quietly closed it again. The hardware is excellent — but the app's dashboards feel designed for compliance rather than insight. I wanted to answer simple questions like "how many days did I actually go to the gym this month?" or "is my weights trending up?" and I couldn't get there without clicking through five menus.
So I built my own.
The Problem with Technogym's App
The Technogym ecosystem tracks everything: every rowing stroke, every set, every kilogram lifted, every step on the treadmill. The raw data is incredibly rich. But the native app surfaces it in a way that makes it hard to spot trends, compare months, or get an at-a-glance view of your progress.
My specific frustrations:
- No meaningful weekly or monthly aggregation across session types
- No way to know if my average weights lifted increasing over time
- Calorie and distance stats buried per-session with no roll-up view
- No "gym visits per week" concept — just individual activity logs
The obvious solution would be to use the Technogym API directly. I looked into it. Getting API access requires a business partnership with Technogym. As an individual developer and gym-goer, that door is closed.
But there's a workaround: you can export your own data.
The Data Export
Technogym lets you request a full data export from the app. You get a ZIP file containing four JSON files — your profile, body composition measurements, every gym session with full per-set breakdowns, and outdoor activities.
My export had 2,668 indoor activity records going back two years and 408 biometric measurements. The indoor activities file is the richest — each record contains the top-level session metrics plus individual set data including weight, reps, and duration.
One quirk: there are no human-readable exercise names. Each exercise is identified by an internal UUID. You have to infer what it was from the metrics present — if a record has rowing distance and stroke rate metrics, it's a rowing session; if it has weight and rep data in its sets, it's strength training.
I can re-download this export every few days to keep the dashboard fresh.
The Build: Web + Android from One Codebase
I wanted this on two surfaces:
- A web app — to open on any browser and share a view with my trainer
- An Android APK — to check on my phone after a session
Expo with React Native was the obvious choice — one codebase, two targets. The web app is deployed to GitHub Pages automatically on every push. The Android APK is built via EAS Build (Expo's cloud build service) — the free tier gives 30 builds per month, which is more than enough.
The entire ZIP file is parsed client-side. Your data never leaves your device.
Interesting Problems Along the Way
What "A Gym Visit" Actually Means
The Technogym export gives you one record per exercise — a typical gym session generates 10–15 records. So counting records as "sessions" would give you 100+ per week, which is meaningless.
Looking at the timestamps, every record from a given gym visit clusters within 1–2 hours on the same calendar day. So the right definition is simple: a gym visit = a distinct calendar day with indoor activity. That single insight turned a useless metric into one of the most useful charts in the app.
The Timezone Bug
I'm in Australia (UTC+10). The app was grouping all my April sessions into the March bucket — every month appeared one step behind. The cause was subtle: when converting a date to a string key for grouping, I was using the UTC date instead of the local calendar date. Midnight on April 1st in Sydney is still March 31st in UTC, so the bucket ended up in the wrong month. Once I switched to using local date methods, everything snapped into place.
Keeping Charts and Logic Separate
The rule I enforced throughout: no data transformation inside chart components. Every chart receives a plain array of pre-computed values. All the filtering, grouping, and aggregation lives in a dedicated hooks layer.
This paid off immediately when adding the Avg / Total toggle to charts like Weight Lifted and Calories Burned — the chart component just holds the toggle state and passes it to the hook. The chart itself doesn't change at all.
What I Can See Now
The dashboard has five tabs:
Overview — Gym visits per week/month, avg visits/week, avg calories per visit, activity type breakdown, training load (total active minutes), and metabolic intensity.
Biometrics — Weight, body fat, muscle mass, BMI and other body composition metrics as trend lines over time.
Workouts — Calories burned (indoor vs outdoor), total weight lifted, cardio distance — all with total/average toggles.
Cardio — Distance, calories, pace (in min:sec per km, green = fastest period), and elevation gain.
Strength — Weight lifted and rowing performance (distance + power) with avg/total toggle.
The most useful views for me personally: weights lifted trend and gym visits per week — a simple bar chart that makes consistency (or the lack of it) very visible.
Sharing with My Trainer
The web app lives at a public GitHub Pages URL. Before a session, I open the app, upload my latest export ZIP, and share the URL. My trainer can see exactly what I've been doing — session frequency, calorie burn by type, weight progression — without needing any account or login.
It's also a much better conversation starter than trying to scroll through the Technogym app together.
What's Next
A few things I'd like to add:
1RM trend — the export includes an estimated one-rep max metric per strength session
Body composition overlay — weight, fat mass, and muscle mass on a single chart
The data's all there. It's just a matter of building the views.
Code
The full source is on GitHub: github.com/kanurag4/technogym-dashboard
If you're a Technogym user frustrated with the native app's dashboards, fork it and point it at your own export. The ZIP format appears consistent across accounts — the parsing should work for any Technogym user.
Built with Expo, React Native, NativeWind, react-native-gifted-charts, and JSZip. Deployed to GitHub Pages and Android via EAS Build.
Top comments (1)
Showing absolute KPI values without a benchmark line next to them is one of those design choices that feels neutral but actually pushes users into a bad reading. RPS $1.20 looks fine in isolation, but next to "industry median $0.90 / top quartile $2.00" it suddenly says "above median, gap to top quartile". The relative-to-benchmark display is what makes the dashboard usable for non-analysts.