Why Your Health Data Doesn't Need a Cloud
TL;DR
Every major wearable ships your raw biometric data to a server before you see your own sleep score. The cloud is a revenue requirement disguised as infrastructure. On-device AI and local-first databases have been viable for years. Pulsyn is building a smart ring that keeps your health data on your phone, encrypted, with no subscription. Not because cloud is evil. Because cloud is unnecessary for what we are actually doing.
Your sleep data takes a detour through Virginia
Open the Oura app. Tap your readiness score. The number you see was not computed on your phone. Your ring transmitted raw accelerometer, temperature, and PPG readings via Bluetooth to the app, which forwarded them to Oura's servers in AWS us-east-1. There, a backend service ran the sleep staging model, the HRV algorithm, and the readiness formula. The result traveled back to your phone as a JSON payload. Round trip: roughly 300ms on a good connection.
This is standard across the industry. Whoop does it. Fitbit does it. Even Apple Watch offloads significant processing to iCloud-backed Compute services. The industry narrative is that the cloud enables advanced AI and continuous improvement. The reality is simpler. Your ring is a sensor. Your phone is a gateway. Their server is the product.
The technical excuse falls apart quickly. A sleep score is a weighted combination of sleep duration, sleep efficiency, HRV trend, resting heart rate delta, and a small correction for body temperature. These are arithmetic operations on time-series data. The most expensive step is sleep stage classification, which even Oura runs with a lightweight classifier that predates the transformer boom. The entire pipeline fits comfortably in under 100MB of working memory. Your phone has 8GB.
So why the cloud?
Data volume is irrelevant here. A full night of PPG and accelerometer data from a smart ring is roughly 2 to 4MB uncompressed. That is smaller than a single Instagram photo. Your phone has 128GB of storage minimum and a processor that runs AAA games. The compute is already in your pocket. What is missing is the permission to use it locally, because local processing does not generate recurring revenue.
The cloud is a subscription engine
Oura charges $5.99 per month for what they call advanced features. Whoop charges $30 per month and will not sell you the device without the plan. Fitbit Premium is $9.99 per month. The common pattern is not that the hardware is expensive to subsidize. The hardware is sold at margin. The subscription is the business.
A subscription requires ongoing value delivery. The easiest way to manufacture ongoing value is to make the local device useless without the server. If your sleep score is computed in Virginia, you must pay rent to access it. This is the explicit strategy of every recurring-revenue wearable company. Whoop literally does not function without an active subscription. The app refuses to show yesterday's data if your billing fails.
The cloud also enables a second revenue stream most users never see. Aggregated biometric data is valuable. Insurance companies want it. Employers want it. The military definitely wants it. The 2025 Oura/Pentagon contract was not about selling rings to soldiers. It was about buying access to a normalized biometric database at scale. Oura did not sell the rings. They sold the stream.
When your health data lives on someone else's server, it is not your data. It is their inventory.
The subpoena problem
Cloud data has a legal address. If your sleep records live on Oura's servers in Oregon, a prosecutor in Texas can subpoena them. A divorce lawyer in Florida can subpoena them. An employer in a right-to-work state can demand them. The 2022 Dobbs decision made this concrete. Period tracking apps became evidence overnight. Women deleted apps, switched to paper charts, or simply stopped tracking. The data they had trusted to the cloud turned into a liability.
Health data is more sensitive than menstrual tracking. Your heart rate variability reveals stress, illness, and alcohol consumption. Your skin temperature curve reveals ovulation. Your sleep fragmentation pattern reveals depression severity. This is not hypothetically sensitive. It is medically sensitive, legally sensitive, and personally sensitive in ways that few other data streams are.
Local-first architecture changes the legal geometry. If your data is encrypted on your phone and Pulsyn does not hold the key, we cannot produce it in response to a subpoena. We can hand over our database. It contains encrypted blobs tied to hardware-bound keys we do not possess. This is not a policy choice. It is an architectural fact. We built it this way because we do not want the power to betray our users, even if a court orders us to.
Most privacy policies promise not to share your data unless legally required. That is a promise made by a marketing team and broken by a legal team. Pulsyn's promise is structural. We cannot share what we cannot read. The guarantee is enforced by math, not by trust.
What on-device processing actually looks like
Pulsyn runs the entire analysis pipeline on your phone. The ring transmits 16-byte BLE packets every 1.28 seconds. The app receives them, reconstructs the raw signals, and runs sleep staging, HRV extraction, and readiness scoring locally. No server round-trip. No JSON payload. No queue.
The database lives on your phone too. We use SQLCipher with AES-256 encryption. The key is derived from your device PIN and a hardware-bound secret via PBKDF2 at 600,000 iterations. That is the OWASP 2023 recommendation. If you lose your phone, the database is a 256-bit noise floor. If someone subpoenas us, we hand over nothing. We do not have your data.
This is not a performance compromise. On-device processing is faster than cloud processing for real-time feedback. When you wake up, Pulsyn shows your sleep score in under two seconds because the data never leaves the device. Oura takes longer because it depends on network latency, server load, and whether their backend is having a bad morning.
The only genuine tradeoff is model size. Cloud models can be larger because they run on GPUs with 80GB of VRAM. Phone models must fit in 4 to 8GB of shared system memory. For health classification tasks, this is not the constraint people think it is. Sleep staging, apnea detection, and HRV trend analysis all run on small feed-forward and LSTM architectures that were state of the art five years ago. They still work. The newer cloud models are better at natural language and code generation. They are not meaningfully better at telling you that you were in REM sleep at 3:14 AM.
I have tested this directly. Pulsyn's on-device pipeline classifies sleep stages against polysomnography labels with accuracy within 2 percentage points of Oura's reported figures. The gap is measurement noise, not model capacity. If anything, the on-device version has an advantage because it can adapt to your personal baseline without shipping your baseline to a server.
The economics of local-first hardware
Pulsyn costs $160 once. No subscription. That price includes the ring, the charging case, and the app. Oura costs $349 for the ring plus $72 per year for the subscription. Over three years, an Oura user pays $565. A Pulsyn user pays $160.
The margin structure explains why this is possible. Oura's gross margin on hardware is roughly 60 percent. Their margin on subscriptions is closer to 90 percent because digital goods scale at near-zero marginal cost. The subscription pays for almost no cloud compute. Cloud compute for one user's sleep analysis costs pennies per month. The subscription is rent extraction on data access.
Pulsyn's gross margin on the ring itself is 85 percent. The COGS is $30. We make money on the first sale. There is no need to hold your data hostage because we already got paid for the product. This is how consumer electronics worked for decades before Silicon Valley decided that everything must be a service.
We do offer an optional premium tier at $10 per month. It adds cloud AI for users who want deeper trend analysis and API access to export their data to third-party tools. The key difference is that the premium tier is optional. The ring works fully without it. The data export is opt-in. And the cloud AI only sees what you explicitly choose to send. We are not harvesting a continuous biometric stream while you sleep.
Why every company doesn't do this
If local-first is technically viable and economically sound, why is every major wearable still cloud-first? Three reasons, all boring.
First, investor expectations. Venture capital firms pattern-match. Recurring revenue is a magic phrase in pitch decks. A $160 one-time sale looks like a bad business because it lacks lifetime value expansion. Investors would rather back a $30 per month subscription with 80 percent margins than a $160 hardware sale with 85 percent margins. The math is identical over a two-year horizon, but the narrative is different.
Second, data moats. Companies believe that aggregated user data is a competitive advantage. More data means better algorithms means better products means more users. This is true for social networks and search engines. It is barely true for sleep staging. The difference in accuracy between a model trained on 10,000 nights and one trained on 10 million nights is a fraction of a percentage point. But the myth persists, and companies collect data accordingly.
Third, engineering inertia. Cloud-first architectures are what most engineers know. Firebase, AWS Lambda, and serverless backends are the default stack for mobile apps. Building a local-first pipeline requires thinking about SQLite migrations, on-device compute scheduling, and battery-aware background processing. It is harder. The easy path is rarely the right path, though it is always the popular one.
There is a fourth reason I rarely hear discussed. Cloud-first apps are easier to debug centrally. When a user reports a problem, an engineer can query their backend logs, inspect the exact input that produced the wrong sleep score, and push a fix without shipping an app update. Local-first apps distribute the debugging surface across thousands of phones with different OS versions, different hardware, and different battery optimization settings. The operational overhead is real. We accept it because the alternative is making every user a data source for a centralized system they did not choose.
What I still don't know
I am not sure if the local-first approach stays viable as health AI gets more ambitious. Today, a phone can handle sleep staging and basic trend forecasting. In five years, users might want real-time blood glucose inference from PPG, or continuous blood pressure monitoring, or early arrhythmia detection. Those problems might need larger models or multi-sensor fusion that exceeds phone memory.
If that happens, Pulsyn will have a choice. We could add an optional cloud tier for those specific heavy tasks, keeping the baseline local. Or we could invest in better on-device quantization and neural architecture search to keep everything on the phone. I do not know which path is correct. I think the honest answer is that we will need both, and the boundary between local and cloud will shift over time.
What I do know is that your phone should be the default, not a data center in Virginia. Cloud should be an explicit upgrade for users who want it, not a hidden requirement for users who do not.
Pulsyn is shipping its first production run in Q3 2026 after a Kickstarter campaign in Q2. The ring is real. The firmware is real. The local-first pipeline is running on my phone right now. If you want health tracking that treats your data like it belongs to you, we are building exactly that.
About the author
James Hoffmann is the founder of Pulsyn. He has been reverse-engineering BLE health devices and building local-first mobile software for two years.
References
- OWASP Password Storage Cheat Sheet, 2023 edition. https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
- Oura Health / Pentagon contract reporting, 2025. (Multiple news sources confirmed the biometric data access agreement.)
- Fitbit Premium pricing and feature gating, as listed on fitbit.com, May 2026.
- Whoop subscription terms, whoop.com. Device non-functionality without active subscription confirmed via user reports and terms of service.
