Monk — the restraint is the product.
Most "focus" apps surveil you to keep you engaged — the opposite of focus. Monk is built on one rule: it should know nothing about you. No internet permission, no accounts, no analytics, no cloud. It can't phone home even if it wanted to, because the permission to do so was never declared.
The problem
The productivity category has a contradiction at its heart: apps that promise to help you focus do it by holding your attention — accounts, cloud sync, behavioral analytics, streaks, nudges. To keep you engaged, they have to watch you. That's the opposite of what focus is.
Monk takes the other position. It silences your messaging noise and auto-replies while you're heads-down — but it processes everything in memory, stores no message history, and has no way to send anything anywhere. The discipline isn't a feature bolted on; it's the whole design.
Who it's for
Privacy-conscious people who run timed or open-ended focus sessions and still need to look available — auto-replying to messages from the apps they use (the chat apps everyone has), without handing a focus tool their conversations, their identity, or a network connection.
Product & journey
A single, calm loop
- Onboard — a three-screen flow: the idea, the privacy promise, and the one permission Monk actually needs (notification access).
- Begin — pick a duration (30m, 1h, 2h, custom, or indefinite) and tap the orb. A foreground service starts; counters reset.
- Focus — an "END" orb, a countdown, and live counters for messages silenced and replies sent. Optional Do-Not-Disturb and a "deep focus" mode that keeps you in the app.
- End — tap to stop; DND is restored, the service stops, and the session is forgotten.
Architecture
The architecture is defined by a boundary the app cannot cross. There is no
INTERNET permission in the manifest and no HTTP library in the build, so
everything — notification handling, auto-replies, counters — happens on-device, in memory.
Auto-reply uses Android's notification quick-reply API, with an accessibility-service
fallback.
Craft & challenges
- Proving a negative — the strongest privacy claim is one the OS enforces. Omitting
INTERNETentirely means the app cannot exfiltrate, even maliciously; release builds also strip logs so nothing leaks to logcat. - Replying without reading — Monk answers messages via the system notification quick-reply (RemoteInput) and a per-sender cooldown, with an accessibility-service fallback for apps that don't expose a reply action — all without touching any chat database.
- Reliable focus — a special-use foreground service that survives process death and reboot, with a persistent status notification and live counters.
- Telemetry-free stats — the "silenced / replies" numbers are in-memory session counters, not analytics; nothing is persisted or sent.
Honest scope: the contact-whitelist and per-app toggle UIs are built but not yet fully wired into the listener — noted here rather than overstated.
Selected screens

(capture pending)
(capture pending)