How Pulsyn Works Without a Login Screen
TL;DR
Most health apps start with a login form because their business model requires your email before their product requires your data. Pulsyn starts with a heart rate graph because the app stores everything locally on your phone and has nothing to authenticate against. The PIN you set is for encryption, not identity. We literally cannot delete your account because we never created one.
The first screen you see is data, not a form
Open Oura. Open Whoop. Open Fitbit. The first screen is a login wall. Email, password, maybe a Google OAuth redirect. You cannot see your own data until you prove to a server in Virginia that you are still you.
This is not a design choice. It is a business architecture. The login wall exists because the app is a client to a remote database that holds your biometric stream. You do not own the database. You rent access to it, usually for $5.99 to $30 per month.
Pulsyn does not have this architecture. The app stores its database in the phone's sandboxed storage, not on a server. When you open Pulsyn for the first time, there is no login screen. There is no password field. There is no "Forgot your password?" link because there is no password to forget. The first screen shows your last sync, your last sleep score, your current resting heart rate. Or it shows empty state text if you have not synced yet. But it never shows a form.
This is possible because the Pulsyn app was built backward from the industry standard. We started with the constraint that the user's health data should not require an internet connection to exist. That constraint eliminates the need for user accounts, authentication servers, session tokens, and the entire backend user table that most apps treat as infrastructure.
The absence of a login screen is the most visible signal of a deeper architectural difference. When you delete Oura, your data survives on their servers. When you delete Pulsyn, your data dies with the app. That is the correct relationship. The data lives where you live.
Why every other health app demands an account
The wearable industry runs on recurring revenue. Oura charges $72 per year. Whoop charges $30 per month. Fitbit Premium is $9.99 per month. The hardware is a sensor. The real product is the dashboard, and the dashboard lives on a server.
To sell that server access, the company needs to know who you are. They need an account to bill. They need an account to enforce cancellation. They need an account to track engagement metrics and reduce churn. The login screen is the first step in a funnel that ends with your credit card.
There is a secondary reason that sounds better in press releases: cross-device sync. If you buy a new phone, the company wants to restore your data. If you use a web dashboard, the company needs to associate your ring with your browser session. The cloud solves this. But the cloud also creates a dependency that did not exist before. Your health data now requires a company's continued operation to remain accessible. If Oura goes under, your data goes with it. If you cancel Whoop, your data is deleted per their terms. The account is both a convenience feature and a lock-in mechanism.
The privacy angle is equally direct. An account ties your biometric identity to your legal identity. Your email, your payment method, your IP logs, and your heart rate variability all share the same user ID. This is not a conspiracy theory. This is how databases work. When Oura signed the Pentagon contract in 2025, the data they delivered was structured by user account. The architecture made extraction trivial.
RingConn avoids subscription fees, yet still requires an account. The app asks for your email during onboarding. The data is stored in the cloud. The lack of a subscription fee is a pricing change. The architecture is unchanged. The account still exists. The link between your body and your identity still exists. The company still has the ability to change its terms later.
The architecture: no backend user table
Pulsyn's app runs on a local SQLite database encrypted with SQLCipher. The database lives in your phone's internal storage. There is no users table in a remote Postgres instance. There is no auth_sessions table. There is no OAuth callback URL registered with Google or Apple.
When you pair the Pulsyn ring to your phone, the app establishes a BLE connection and pulls the day's data into the local database. The AI models that generate your sleep score, your stress score, and your recovery metrics run on the phone itself. They do not call an API. They read from the local database and write back to it.
The optional premium tier adds cloud AI for users who want deeper analysis. This is opt-in, not opt-out. The free tier is the full product. The cloud is an upgrade, not a requirement.
This architecture has a cost. We lose the ability to do cross-device sync out of the box. We lose the ability to show you a dashboard on a browser without building a separate local-first web runtime. We lose the ability to recover your data if you lose your phone and did not make a backup. These are real tradeoffs, and we are honest about them.
But what we gain is a health app that does not phone home. There is no telemetry. No analytics SDK reporting which screens you tap. No A/B testing framework measuring how long you stare at your sleep score. No server logging your IP address when you check your heart rate at 3 AM. The app is silent because it has no one to talk to.
Even the App Store analytics are limited. Apple provides aggregate download numbers, but we cannot see which users open the app daily or which features they use. We do not know how many people check their sleep score at 7 AM versus 10 AM. This makes product development harder. We cannot run data-driven experiments on user behavior. We have to talk to users instead. That is slower. That is also the only way to respect them. I think this is the right tradeoff, though I have had investors argue that our lack of analytics makes us blind to retention issues. They are not wrong. We are blind to retention issues. We chose to be blind rather than to surveil. Apple provides aggregate download numbers, but we cannot see which users open the app daily or which features they use. We do not know how many people check their sleep score at 7 AM versus 10 AM. This makes product development harder. We cannot run data-driven experiments on user behavior. We have to talk to users instead. That is slower. That is also the only way to respect them.
The PIN is for encryption, not authentication
When you first set up Pulsyn, the app asks for a 4-digit PIN. This is not a password. It is not checked against a server. It is not used to prove your identity to us. The PIN derives a key through PBKDF2. That key encrypts the local database. The PIN exists so that if someone steals your phone and cracks the sandbox encryption, they still face SQLCipher's AES-256 layer.
We do not know your PIN. We cannot reset it. We cannot mail you a reset link because we do not have your email. If you forget your PIN, you create a new local database and re-sync from the ring. The ring stores several days of raw data internally, so you lose historical trends, not the current day. This is a hard edge case, but it is a hard edge case that respects your ownership. The alternative is a cloud-based password reset that requires us to store your contact information and maintain an identity infrastructure. We chose the harder user experience because the easier one creates a power imbalance we do not want.
The PIN is only four digits. We considered longer PINs, alphanumeric passwords, and biometric access. A longer PIN is more secure but harder to enter every time you open the app. Biometric access is convenient but ties the encryption to the phone's biometric keychain, which behaves differently across manufacturers and can be reset by a phone reboot. Four digits is the balance we picked. It is not perfect. It is good enough for a health app where the threat model is a stolen phone, not a state-level adversary.
What happens when you switch phones
This is the most common objection to local-first architecture. "What if I get a new phone?" The answer is that we built an export system. The Pulsyn app can write your entire database to an encrypted file that you move however you want. AirDrop it. Email it to yourself. Put it on a USB drive. The file is encrypted with your PIN, so it is safe in transit. Import it into the new phone, enter your PIN, and your full history is back.
This is more friction than automatic iCloud restore. It is also more control. You know exactly where your data is because you are the one moving it. There is no third-party server that could be subpoenaed, breached, or acquired. The export file is yours in the same way a Word document is yours. You can delete it, archive it, or analyze it with external tools.
I am not sure peer-to-peer sync between two phones is a feature we will ship before launch. It is technically possible over local WiFi with encrypted handshakes, but the user experience is tricky and we have not found an interface that feels obvious enough. For now, the encrypted export is the answer. It is not perfect. It is sufficient.
What happens when you want to leave
Canceling a subscription app is intentionally painful. You have to log in, go to billing, find the cancellation flow, and then discover that your data is deleted or locked. Oura's data export exists but is limited. Whoop deletes your data immediately upon cancellation. Fitbit lets you export but the format is a mess.
With Pulsyn, there is no account to cancel. There is no subscription to stop. If you stop using the app, your data stays on your phone until you delete the app. If you delete the app, the data is gone because it was never anywhere else. The entire lifecycle of your data is visible to you. You are not negotiating with a company for access to your own body measurements.
The database uses standard SQLite. The schema is straightforward. Tables for sleep sessions, heart rate samples, and HRV readings. No user profiles. No social graphs. No tracking tables. If you want to write a Python script to graph your HRV trends directly from the export file, you can. If you want to write a Python script to graph your HRV trends directly from the export file, you can. The data is not trapped in a proprietary format. It is not held hostage by a Terms of Service clause. You own the file because you own the device.
About the author
James Hoffmann is the founder of Pulsyn. He has been building local-first health software for two years and holds the opinion that most cloud infrastructure in consumer health is a solution to the vendor's problem, not the user's.
References
- Oura Health Terms of Service, "Data Retention Upon Cancellation," accessed May 2026.
- Whoop Membership Terms, "Effect of Cancellation on Data," accessed May 2026.
- OWASP Cheat Sheet Series, "Password Storage," 2023. https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
- SQLCipher Documentation, "Security Features and Design." https://www.zetetic.net/sqlcipher/design/
