Your Sleep Tracker Should Work on a Plane. Ours Does.
TL;DR
Most health trackers treat your phone as a dumb pipe to their cloud. The ring collects data, the app forwards it, and the actual sleep score gets computed on a server in Virginia. When you turn on airplane mode, the app becomes a brick. Pulsyn's architecture assumes the opposite: your phone is the computer, the database lives locally, and the cloud is an optional extra. That decision changes everything about where you can use it.
The moment it breaks
I was on a flight from Phoenix to Seattle last month. Six hours, no Wi-Fi, phone in airplane mode because the battery on my Pixel 7 dies fast and I needed it alive when I landed. I wear a smart ring. I wanted to know how I slept in a cramped seat with a crying baby two rows back.
I opened the app. Oura. The spinner turned for twelve seconds. Then: "Unable to connect. Please check your network and try again." My data was on the ring. The ring was on my finger. The phone was in my hand. But the sleep score lived on a server I could not reach, so the app refused to even show me yesterday's data from before I boarded.
This is not an Oura bug. It is the intended architecture. Oura's app does not calculate your readiness score. Their servers do. The app is a viewer for a remote database. When the pipe breaks, the viewer goes blank.
Whoop is the same. Fitbit is the same. Garmin is slightly better (it caches some recent data locally), but the deeper analytics still require a sync to Garmin Connect. The subscription model almost demands this design. If the value lives in the cloud, you must stay connected to extract it.
Why they need the internet
The reason is economic, not technical. Your ring generates about 2 kilobytes of biometric data per minute. Over eight hours of sleep, that is roughly 1 megabyte. A modern phone can process 1 megabyte of time-series data in under a second. The computation required for a sleep score (filtering accelerometer drift, detecting motion epochs, mapping heart rate variability to recovery) is not exotic. It is linear algebra and some heuristic thresholds.
But if Oura computed your score on-device, they could not justify the $5.99 monthly subscription. The subscription is not for storage. One megabyte per night costs fractions of a penny to store, even at retail cloud prices. The subscription is for access to the compute layer they deliberately placed on their servers instead of your phone.
This is the cloud-as-paywall model. The device is the sensor. The app is the modem. The value is the server, and the server is gated by a recurring fee. It is a perfectly rational business decision if your goal is recurring revenue. It is a terrible user experience if you are on a plane, or a hiking trail, or in a rural hospital with spotty cell coverage, or in any country where roaming data costs $15 per megabyte.
The technical cost of on-device processing is negligible. A Snapdragon 8 Gen 3 can run a 1 billion parameter model at roughly 20 tokens per second. A sleep score requires maybe 2,000 tokens of context (your heart rate samples, motion events, temperature drift, SpO2 readings). That is under two seconds of inference on a modern phone, and perhaps five seconds on a three-year-old mid-ranger. The battery cost is a few milliamps. The engineering cost is a few weeks of optimization to get the model quantized and the inference pipeline stable.
The business cost, for Oura, is existential. If the score computation happens on your phone, the subscription becomes a harder sell. They would have to pivot to selling software features (coaching, trends, community) rather than selling access to your own data. Some companies are trying this. Whoop still charges $30 per month but now bundles strain coaching and community challenges. Fitbit Premium adds workout videos. The subscription is slowly becoming a content bundle rather than a compute gate. But the legacy architecture remains, and the legacy architecture still fails when the pipe breaks.
I have tested this across four brands. Oura Gen 3: full brick in airplane mode. Whoop 4.0: brick, with the added insult that the device itself has no screen or storage, so without the app-to-cloud pipe, it is literally a dead rubber strap. Fitbit Sense 2: partial brick. It shows raw heart rate, but the sleep stages and SpO2 summary refuse to load without a sync. Garmin Fenix 7: best of the bunch, but stress tracking and Body Battery still need a server round-trip.
What offline-first actually means
Offline-first does not mean "we cache some stuff." It means the primary data store and the primary compute layer live on the device you are holding. The cloud is a backup, not the brain.
For Pulsyn, this means three things:
The ring streams raw data to your phone over Bluetooth Low Energy. The phone stores it in a local SQLite database encrypted with SQLCipher. The encryption key is derived from your PIN using 600,000 PBKDF2 iterations. We do not know the key. We do not have the database. It lives on your phone's flash storage.
The sleep score, readiness score, and all derived metrics are computed on your phone by an AI model that runs entirely on-device. Not in the cloud. Not on our servers. On your Snapdragon or Tensor or A-series chip. The model sees your data for the few milliseconds it takes to run inference, then forgets it.
Sync to the cloud is opt-in and manual. If you never create an account, your data never leaves your phone. If you do create an account (for features like cross-device backup), the sync happens when you choose, over a connection you trust.
This is the opposite of the Oura model. Oura assumes the cloud is primary and the device is a peripheral. Pulsyn assumes your phone is primary and the cloud is a peripheral.
The architecture
I want to be specific about what this costs, because local-first architecture is not free. It has real tradeoffs.
The database is SQLite with SQLCipher. Every read and write is AES-256-GCM encrypted. That adds about 15% CPU overhead versus unencrypted SQLite, and it means we cannot use some of the more exotic SQLite extensions that expect raw page access. We accepted that tradeoff. The encryption is non-negotiable.
The on-device AI model is quantized to run within the memory budget of a mid-range Android phone. That means 4GB RAM devices are supported, but we cannot load a model larger than about 1 billion parameters without risking out-of-memory kills on older phones. We are at the edge of what is feasible. I am not sure if we can grow the model much larger without raising our minimum spec. That is an honest constraint.
The inference runs in a background thread pool with priority set below UI rendering but above most other background tasks. This means your animations do not stutter while the sleep score calculates, but it also means a very heavy game or video export running in parallel could delay the analysis by a few minutes. In practice, most users calculate their sleep score while the phone is idle on a charger in the morning, so this is a theoretical concern more than a real one. But I want to mention it because "on-device" does not mean "instant magic." It means "your phone does the work, subject to your phone's limits."
The BLE protocol between ring and phone sends data in 16-byte packets. We batch 512 packets before writing to disk, which keeps the radio awake for shorter bursts and saves battery. The ring's own MCU stores roughly 24 hours of raw data in its internal flash. If you lose your phone, you have a day to find it before the ring starts overwriting old data. I would like that buffer to be longer, but the ring's NOR flash is 4 megabytes total, and firmware, calibration tables, and the bootloader eat most of it.
Each 16-byte packet contains a command ID, up to 14 bytes of payload, and a checksum. The payload format changes based on the sensor: heart rate uses 2-byte unsigned integers at 1 Hz, accelerometer uses 3-axis signed 12-bit samples at 25 Hz (packed into 6 bytes per sample), and temperature uses 4-byte floats every 30 seconds. The ring compresses repeated identical samples (like zero motion when your hand is still) using run-length encoding before transmission. This gets our effective data rate down to about 1.2 kilobytes per minute instead of the raw 2.0 kilobytes. Every byte matters when you are running on a 20-milliwatt radio.
The BLE protocol between ring and phone sends data in 16-byte packets. We batch 512 packets before writing to disk, which keeps the radio awake for shorter bursts and saves battery. The ring's own MCU stores roughly 24 hours of raw data in its internal flash. If you lose your phone, you have a day to find it before the ring starts overwriting old data. I would like that buffer to be longer, but the ring's NOR flash is 4 megabytes total, and firmware, calibration tables, and the bootloader eat most of it.
The edge cases
Offline-first sounds like a niche feature until you list the places where people actually want to track their health without reliable internet.
Airplanes. Twelve million people fly daily. Most long-haul flights still charge for Wi-Fi, and most of it is too slow for app sync anyway. If you land after an overnight flight and want to know how you slept before your morning meeting, an offline-dependent tracker gives you nothing.
International travel. Roaming data is expensive, airport Wi-Fi is captive-portal hell, and some countries block or throttle cloud services unpredictably. I have been in places where Oura's API endpoints simply time out. A tracker that needs the cloud is a tracker that works better in San Francisco than in São Paulo.
Hiking and camping. If you are tracking recovery on a multi-day backpacking trip, you probably do not have cell service. Garmin handles this better than most because their heritage is GPS devices for the backcountry. But even Garmin pushes you toward their cloud platform for long-term trends.
Hospitals and clinics. Many hospitals restrict personal devices or block cellular signals near sensitive equipment. If you are tracking recovery after surgery, the place where you most need health data is often the place where cloud-dependent trackers fail.
Subways, elevators, basements, rural highways. These are not exotic edge cases. They are normal life for billions of people.
There is also the less obvious case: corporate networks. Many employers run aggressive firewalls and TLS inspection proxies that break API calls in ways the app does not expect. I have seen health apps fail on office Wi-Fi not because the internet is down, but because the app's HTTP client does not trust the corporate CA certificate. A local-first app does not care about your employer's middlebox. It does not make HTTPS calls to score your sleep. The only network traffic is the optional cloud sync, which you control and which fails gracefully instead of bricking the core experience.
The tradeoff
I want to be honest about what you give up.
First, device storage. The local database grows by roughly 30 megabytes per month of sleep, activity, and biometric logging. That is small by modern standards, but on a 64GB Android phone with a full camera roll, it matters. We will eventually add automatic compaction and archival, but right now the database just grows.
Second, cross-device portability. If you switch from iPhone to Android, your health data does not follow you automatically. It is locked to the local database on your old phone. You can export a backup file and import it manually, but that is friction. Cloud-first trackers handle this without friction because your data lives in their account, not your device.
Third, compute limits. On-device AI cannot match the depth of cloud models with larger context windows and more parameters. Our sleep analysis is accurate. I believe it is competitive with Oura's. But if you subscribe to our optional premium tier, you get access to cloud AI with deeper context windows and more nuanced pattern recognition. The base model is free and local. The premium model is smarter and remote. We are transparent about that split instead of pretending the free tier is somehow "crippled" to push you upward.
Fourth, battery. Running inference on your phone uses more local CPU than simply uploading raw data and letting a server do the work. The difference is about 3-5% additional battery drain per night. We think that is acceptable. You might not.
What Pulsyn will not do
We will not claim that local-first is always better. It is better for privacy. It is better for resilience. It is better for user control. But it is worse for easy multi-device sync, and it is worse for users who want the most computationally intensive analysis possible without paying for premium.
We will not build a cloud-primary version to chase feature parity with Oura. That would be a different product with a different business model. If you want a cloud-native health tracker with a subscription, Oura is a reasonable choice. If you want a device that works on a plane, in a hospital, or in any country with bad cell service, Pulsyn is what we are building.
We will not store your data by default and ask you to trust our privacy policy. The privacy policy is irrelevant when the database is on your phone and we do not have the key. I would rather architect around not having your data than write a longer terms-of-service document.
The real test
The real test of a health tracker is not how it performs on a desk in San Francisco with gigabit Wi-Fi. The real test is how it performs when the infrastructure fails. When the cell tower is down. When you are in airplane mode. When you are in a country that blocks the API. When you are too broke to pay for roaming data.
Your body does not stop generating data when the internet goes out. Your heart keeps beating. Your temperature keeps cycling. Your HRV keeps fluctuating. A tracker that forgets you exist the moment it loses signal is not tracking you. It is tracking its own database.
Pulsyn is built for the moment the connection drops. That is not a edge case. That is the real world.
About the author
James Hoffmann is the founder of Pulsyn. He has been reverse-engineering BLE health devices for two years and believes most wearable companies are building cloud services with jewelry attached.
References
- Oura Subscription Terms, accessed May 2026: oura.com/terms
- Whoop Membership Pricing, accessed May 2026: whoop.com
- Garmin Connect Sync Documentation, accessed May 2026: garmin.com/en-US/connect/
- OWASP Password Storage Cheat Sheet (PBKDF2 recommendations), 2023: owasp.org
- Android Storage Stats (average app size and local database growth), internal Pulsyn testing, 2026
