Review the no-account privacy posture: PainTracker privacy boundary
The account wall is not neutral.
For ordinary apps, it may be a conversion step.
If you want privacy-first, offline health tech to exist without surveillance funding it: sponsor the build → https://github.com/sponsors/CrisisCore-Systems
For sensitive apps, it can be the moment the user decides not to trust you.
Many products ask for account creation before the user knows whether the tool is worth trusting. That may be normal in SaaS, but it becomes questionable when the user wants to record pain, symptoms, trauma notes, legal details, private finances, or anything personally exposing.
PainTracker takes a different path:
core use should not require an account.
Account creation asks for trust before earning it
An account wall is not just a form.
It asks for email. Password. Verification. Terms acceptance. Data storage trust. Recovery trust. Platform trust.
For a sensitive tool, that is a lot to demand before the user has received value.
The user may be tired, in pain, unsure whether the app is safe, or unwilling to create another identity-linked record. They may be on a shared device. They may not want an email trail. They may not know whether this tool will help.
Forcing account creation at that point shifts risk onto the user for the product's convenience.
Sensitive data changes the product equation
Pain tracking can include private details:
- pain severity
- medication notes
- functional limits
- sleep disruption
- work-related pain
- flare patterns
- appointment concerns
- notes the user may not want associated with an account
That information deserves restraint.
If the core task is simply to record what happened, account creation is not automatically justified. It may be useful for sync, backup, billing, or provider access, but those are different features with different trust costs.
No account does not mean no structure
Accountless core use does not mean the product is unstructured.
The app can still organize records. It can still support local history. It can still generate exports. It can still guide the user through a calmer workflow. It can still have paid layers later if those layers are explicit and ethically separated from the basic local task.
The point is not "never have accounts."
The point is:
do not make identity the price of basic private use unless the feature truly requires identity.
When accounts are useful
Accounts can be legitimate.
They can help with cross-device sync, cloud backups, team access, provider portals, subscription management, and recovery across devices.
But those features increase trust in remote systems.
They may add new logging, retention, support, breach, and subpoena surfaces. They can also create confusion about who can see what.
That does not make accounts bad.
It means they should be scoped.
If a feature needs an account, say why. If a feature does not need one, do not force it into the path.
PainTracker's boundary
PainTracker's core use is accountless because the first job is not user capture.
The first job is letting someone record what happened before they forget it.
That boundary matters. Pain records can be useful before they are synced, monetized, shared, or integrated. A user should be able to test the tool privately and decide whether it deserves more trust.
PainTracker does not treat account creation as the front door.
It treats pain recording as the front door.
A design rule
Require an account only when the feature actually needs one.
| Feature | Account needed? |
|---|---|
| Record a pain entry | No |
| Review local history | No |
| Export a summary | No |
| Sync across devices | Probably |
| Provider portal | Yes |
| Team administration | Yes |
That table is not universal, but it is a useful starting point.
The burden of proof should sit with the account requirement, not with the user's desire to begin privately.
Developer checklist
Before putting an account wall in front of a sensitive workflow, ask:
[ ] What can the user do before login?
[ ] Is login technically necessary or commercially convenient?
[ ] What sensitive data is collected before trust is built?
[ ] Can the user test the tool privately first?
[ ] Does account creation improve the user's safety or just the business model?
If the answer is mostly business convenience, say that internally. Do not dress it up as user protection.
The useful takeaway
Accountless core use is not a missing feature.
It is a boundary.
It lets the user test the tool before creating an identity-linked relationship with the product.
Try PainTracker.ca without creating an account.
That is the point. The core tracking flow is designed to be usable before the user is asked to trust a platform.
Support this work
- Sponsor the project (primary): https://github.com/sponsors/CrisisCore-Systems
- Star the repo (secondary): https://github.com/CrisisCore-Systems/pain-tracker