Privacy guide
WakeSage privacy and local-first design
WakeSage is built so alarm behavior stays primarily on-device and understandable without adding ad-tech or account-heavy infrastructure.
An alarm app does not need the same data model as a social app or an ad-supported utility. WakeSage is intentionally narrow: it focuses on scheduling alarms, presenting a wake flow, and storing only the wake-related context needed for that experience.
The product direction is local-first. Settings, schedules, ring histories, and accountability records are meant to stay with the device unless a future feature clearly requires otherwise.
What stays local
- Alarm schedule settings and repeat patterns.
- Wake outcome summaries and readiness history tied to the current device.
- Optional accountability and proof metadata used to evaluate wake completion.
What WakeSage avoids by default
- No ad network SDKs or analytics tracking beacons.
- No account requirement just to set and ring alarms.
- No broad remote profile collection for ordinary wake-up use.
Why support still exists
A local-first app can still publish support and privacy contacts. WakeSage uses the website to document how the product works, what permissions matter, and where users should report reliability issues. The support address is for troubleshooting and policy questions, not for routine tracking.