QYNE
Wearable telemetry turned into a periodised training plan
QYNE gives athletes and academies the intelligence to train like professionals — wearable telemetry, smartphone assessments and sport-specific analysis folded into a personalised, periodised plan. Zinwave is building the platform end to end: an Expo mobile app that pairs with the QYNE band over Bluetooth and reads the phone’s own health store, a NestJS service that normalises every device into a single canonical vocabulary, a React web app sharing the same tokens and domain logic, and the AWS infrastructure underneath it — with health data resident in India.
The challenge
Consumer wearables do not agree with each other. A band, an Apple Watch and an Android phone will each report something called “heart rate variability” using a different algorithm, a different unit convention and a different sampling window. Left unreconciled, the same athlete looks materially different depending on which device happens to be on their wrist that week — which makes any readiness or recovery score untrustworthy the moment someone changes hardware. Solving that is the real product problem, and it has to be solved alongside the unglamorous ones: parsing a proprietary Bluetooth protocol byte by byte, surviving a phone that drops connection mid-sync, and holding health data to a standard a regulator would recognise.
What we did
- Made the canonical metric model the centre of the system. Each source — the band, Apple HealthKit, Android Health Connect — is a provider behind a registry that translates its native vocabulary into one internal representation on ingest. Devices are then an integration detail rather than something the analytics, the screens or the scoring logic ever has to know about.
- Built the mobile app as the gateway rather than a viewer. It speaks the band’s proprietary protocol directly — decoding binary frames into typed records — merges that with whatever the OS health store already holds, caches locally so a lost connection is an inconvenience rather than a gap in the record, and forwards provider-native samples to the backend for normalisation.
- Treated the phone’s own health store as a first-class source, not a fallback. HealthKit and Health Connect run on-device by design, so the app is useful to an athlete who owns an Apple Watch and no QYNE band at all — which materially widens who the product can onboard on day one.
- Structured the client as a Turborepo monorepo so the React Native and React apps share design tokens, API client, types and validation. The web app is the same product as mobile minus the flows a browser physically cannot run, and a token change lands in both without being reimplemented twice.
- Put the backend behind Supabase rather than duplicating it — Supabase issues and owns auth, the NestJS service verifies those tokens and takes responsibility for ingestion, normalisation and derived metrics. The boundary between what a client may read directly and what must go through the service is written down as an architecture decision record, so it stops being re-litigated every sprint.
- Provisioned everything as AWS CDK in ap-south-1, because where health data physically lives is a compliance decision before it is a latency one. Deployments authenticate through GitHub OIDC with scoped roles, so there are no long-lived AWS keys in any repository.
Tech & scope
The outcome
- One canonical model, so a metric means the same thing whichever device produced it — and a new wearable is a provider to add rather than a rewrite.
- Mobile and web built from shared tokens and shared domain logic, keeping one product consistent across two platforms and one small team.
- Health data resident in India on infrastructure declared in code, with no long-lived credentials anywhere in the pipeline.
Building something like QYNE?
Tell us what you are trying to ship. You will get an honest review, a clear plan and a fixed, affordable quote, usually within a day.