Monk — the focus app that couldn’t leak your data if it tried.

The productivity category has a conflict of interest at its heart. Focus apps make money by knowing you — accounts, cloud sync, streaks, behavioral analytics. To sell you concentration, they meter your attention. Meanwhile the phone keeps swinging: studies log 60–90 notifications a day per person, knowledge workers get interrupted roughly every two minutes, and a genuine interruption costs about 25 minutes of depth. The tool that fixes this should be the one app on your phone with no angle.

People feel the conflict even when they can’t name it. 81% of Americans say they’re concerned about how companies use their data; 73% say they have little or no control over it (Pew, 2023). And the category leader in Android auto-reply — 7 million downloads — declares right in its own store listing that it may collect and share your location and app activity, and pipes conversations through cloud AI by design. The market answer to “help me be unreachable” is an app that watches you.

Monk’s answer isn’t a better privacy policy. It’s the removal of the capability. When Pew analyzed a million Play Store apps, 83% requested full network access — and that was a decade ago. Monk sits in the sliver that never asks. The promise “your messages never leave your phone” isn’t marketing copy; it’s a permission the operating system was never granted, and anyone can check.

That discipline generalizes. Everything Monk does — intercepting notifications, replying in place, running sessions that survive reboots — is a reusable pattern for any developer building software for people who cannot afford to be watched. The core is MIT-licensed precisely so it can be taken.

The deep worker

Imagine you’re shipping something hard and your phone takes ninety runs at your attention a day. You don’t need another dashboard about your habits — you need the pings answered and silence until you surface. Interruptions hit knowledge workers about every two minutes, and each real one costs ~25 minutes of depth. Monk is for the overlap: people who want focus without buying it with surveillance.

The person being watched at home

Imagine the person who monitors your phone is someone you live with. In a 2025 global study, 45.7% of adults reported experiencing some form of tech-enabled abuse in the past year, and stalkerware detections run in the tens of thousands annually. For a survivor, every app is a question: what does it store, and who could make it talk? Monk’s answer is structural — it stores no messages, keeps no history, and has no server to subpoena, breach, or coerce. It isn’t an anti-stalkerware tool, and it doesn’t claim to be; what it offers is narrower and provable: an app that holds nothing and transmits nothing adds zero new attack surface to a life that can’t afford any.

The journalist and the source

Imagine your contact list is the story. At least 180 journalists in 20 countries have appeared on commercial spyware target lists. People in that world audit permissions before they install anything — and Monk is the rare app that passes the audit in one line: no INTERNET permission. “Nothing transmitted, ever” is a claim a security desk can verify in thirty seconds.

The developer who needs this foundation

Imagine you’re building for any of the people above — a therapist-referral app, a shelter’s check-in tool, a newsroom utility — and privacy isn’t your feature, it’s your precondition. Monk’s core is the head start: an OS-enforced no-network boundary, an in-memory message pipeline, and session infrastructure that survives reboots. MIT-licensed. Rebrand it, build on it, keep the guarantee.

Three days, and one decision

Day one: the obvious build. Scaffold the whole app the way anyone would — SMS auto-reply through RECEIVE_SMS, SEND_SMS, and READ_SMS, a Room database on standby, cloud backup enabled by default. It worked. It was also three scary permission prompts and a datastore away from being every other app.

Day two: the inversion. The realization that notifications already carry a reply channel — Android’s RemoteInput — so SMS auto-reply needs zero SMS permissions; you answer a text by answering the Messages notification. The same day, the whole posture flips: SMS receiver deleted, Room deleted, backups switched off, and the commit message says it plainly — “Zero-Knowledge architecture.” Deep Focus, Do-Not-Disturb integration, boot resume, and 25-app support land in the same push: four thousand lines in a day.

Day three: the subtraction pass. The rare cleanup that removes more than it adds — net −453 lines. Release builds strip every log call; debug logs redact senders; the notification listener loses 150 lines of scaffolding. Restraint, applied to the codebase itself.

Then the positioning caught up. An MIT license, a README that leads with the conviction, and — most recently — a wiring pass that closed the gaps this page’s own earlier draft disclosed. The product didn’t change direction once; it just kept deleting things that betrayed the rule.

A single, calm loop

Using Monk takes four verbs. Onboard — three screens: the idea, the privacy promise, and the one permission it actually needs (notification access; everything else is optional and asked for in context). Begin — pick 30 minutes, an hour, two, a custom stretch, or infinity, and tap the orb. Focus — the orb turns ink-black, a countdown runs, and two live counters tally the messages silenced and replies sent on your behalf; optional Do-Not-Disturb silences the phone itself, and an optional Deep Focus mode walks you back when you wander. End — tap again: DND is restored, the counters die with the session, and nothing is remembered.

The onboarding page shown here is the whole pitch in four lines — we don’t know who you are; messages never leave your phone; no sign-up, no account, no tracking; works completely offline. Every engineering decision on this page exists to keep those four sentences true.

• Subtraction is the feature. SMS permissions: deleted. Room database: deleted. History screen: never built — the navigation code carries the comment “Privacy: No History screen — we don’t store message history.” The best cleanup commit removed 453 more lines than it added.
• Claims the OS enforces beat promises a policy makes. No INTERNET permission; allowBackup=false; cleartext traffic disabled. The strongest privacy statement in the repo is the absence of a line in the manifest.
• Hold nothing you wouldn’t want to explain. Messages are processed in memory and dropped; the reply cooldown map is wiped every session; the whitelist stores contact IDs, never names; the “silenced / replies” numbers are UI, not analytics — they die with the process.
• Ask for one permission; earn the rest. Onboarding requests exactly one thing: notification access. Do-Not-Disturb, accessibility, and contacts are optional, requested in context, and switch on the moment the user grants them — no nagging checklist screens.
• Calm is a design system. One orb, two numbers, a monochrome ink-on-paper palette with a single brass accent. The status notification updates every 60 seconds, not every second — even the battery is treated with restraint.
• Say what’s unfinished. This page keeps an honest-scope ledger (below), and when it lists a gap, the gap is real — and when a gap gets fixed, the fix lands in the public repo before the claim lands here.

The architecture is defined by a boundary the app cannot cross. Everything happens on-device: a NotificationListener intercepts messages and answers them through Android’s RemoteInput channel, a foreground FocusService owns the session (timer, counters, boot resume), an optional AccessibilityService handles Deep Focus and a best-effort reply fallback, and DataStore holds 13 settings keys — zero message content. There is no network tier because there is no network permission. And the honest answer to “where’s the backend?” is: there isn’t one, anywhere, and that is the product.

An app with no telemetry can’t page anyone when it breaks — so it has to be built not to break, and small enough to audit instead of monitor. Monitoring is inverted here: the operating system is the watchdog, the user’s own device is the dashboard, and the codebase — 4,217 lines of Kotlin across 21 files — is short enough to read in an afternoon.

Resilience is engineered rather than observed. The session runs in a special-use foreground service with START_STICKY restart semantics; the session’s three facts (active, start time, duration) are persisted the moment it begins, so a reboot mid-session resumes with the correct remaining time — verified on the emulator: restart the phone and the countdown picks up where the wall clock says it should, and a session that expired while the phone was off is detected and cleared rather than resurrected. A battery-optimization check deep-links to whitelist the app on aggressive OEMs.

The crash surface is thin by construction: no network stack, no database, no serialization layer, no third-party SDKs beyond AndroidX and Hilt — the categories that generate most production crashes simply aren’t present. Memory sits at ~21–37 MB PSS on the same emulator, and the status notification refreshes every 60 seconds rather than every second. The only statistics the product keeps — messages silenced, replies sent — are computed on-device, shown to the user, and kept by no one.

1 · Proving a negative

Every app says “we don’t collect your data.” Nobody can check. The bar here was different: make the claim verifiable by a stranger in under a minute. The first move is the boundary — don’t promise no exfiltration, remove the capability. With no INTERNET permission in the manifest, the kernel refuses the socket. 83% of Android apps ask for the network; Monk can’t use it without shipping a new APK that any user could diff.

The second move is closing the side doors, one by one. Cloud backup is off (allowBackup=false — Android’s backup service would otherwise happily ship app data to Google’s servers on its own). Release builds strip every log statement via ProGuard (logcat is readable over adb; a leaked sender name in a log line is still a leak), and even debug builds redact senders to M*** or ***1234. There is no database and there are no files — device forensics find 13 settings keys, not conversations. The third move is source: MIT-licensed, ~4,200 lines, rebuildable — the audit is git clone plus aapt dump permissions. The result is a privacy claim built to survive a hostile security review: demonstrated, not asserted.

2 · Replying without reading

3 · The echo problem

Failure modes nobody thinks about until 3 a.m.: your own reply posts a notification, and the listener answers itself, forever. Two people running auto-repliers ping-pong until a battery dies. A chatty group thread collects fifteen “I’m in monk mode” messages in a minute — congratulations, you’re a spam bot now. The defenses are small and layered: a self-reply guard that recognizes and skips Monk’s own words when they echo back; a whitelist gate that lets chosen contacts through untouched; and a per-sender cooldown — 5 minutes by default, tunable from 1 to 60 — so each person gets one courteous answer, not a barrage.

The detail worth a second look is where the cooldown ledger lives: in a plain in-memory map, created when the session begins and destroyed when it ends. This is a rate limiter designed under a constraint most infrastructure never faces — the ledger itself must not exist after the session. Rate limiting that leaves no trace of who messaged you.

4 · Deep Focus, without becoming the thing it fights

5 · A session that refuses to die

A focus session is a promise with a deadline, and Android is an environment that kills processes for sport. The session has to survive the OS’s memory pressure, the user’s reboot, and Doze’s clock games — without holding a wake lock like a barbarian. The machinery: a special-use foreground service (Android 14’s FOREGROUND_SERVICE_SPECIAL_USE with a declared focus_mode subtype — the modern, policy-compliant way to stay alive) with START_STICKY restart semantics; the session’s three facts persisted the moment it starts; and a boot receiver that recomputes remaining time from the wall clock. A 2-hour session with a reboot in the middle ends exactly two hours after it began — and a session that expired while the phone was off is detected and cleared, never resurrected as a zombie. Frugality is part of the reliability story: the timer is a single coroutine delay, the notification refreshes on a 60-second cadence, and persistence costs three DataStore keys, not a battery.

6 · The discipline of one screen

Every element on a focus app’s screen is a bid for attention — which makes screen design a zero-sum game against the product’s purpose. Monk’s home screen holds exactly four things: a word, an orb, a duration, and — in session — two numbers.

The craft is in what the orb carries. Its entire state language is color and a two-second breathing pulse: paper for ready, ink for focused, gray for locked. Commitment gets one 50-millisecond haptic tap. Duration is five pills, not a picker. The counters render in hairline-light type, and the palette is near-black ink on warm paper with a single brass accent that appears almost nowhere — restraint as a visual identity.

Just as deliberate is what’s absent: no tab bar, no streaks, no charts, no red badges, no history screen. The absence of gamification is a feature with a straight face — this app rewards you by not being interesting. Even the status notification plays along, updating once a minute instead of once a second.