People who want structured focus sessions, app-distraction controls, routines, evening reflection, calendar planning, wake-up challenges, and a way to understand personal patterns without making the product a social platform.
Reality
Android application
A personal operating layer for focus, routine, reflection, and more intentional device use.

The problem I chose to solve
The most useful way to understand this project is to start with the friction behind it, then examine the system choices made to address that friction.
Digital wellness apps often track behavior without helping users change the conditions around it; simple timers can be easy to bypass, while productivity systems can fragment focus, sleep, habits, health signals, and calendar planning into separate products. The product concept is to make focus and routine an integrated part of how the Android device behaves.
I designed Reality around a stronger boundary than a standard to-do list: focus tools, app-blocking rules, bedtime awareness, reflections, and wake-up routines operate close to the Android device itself. The app emphasizes local-first personal records and gives users control over optional integrations. AI is an assistant path, not a reason to upload every habit or journal by default.
Where it fits in the real world
A strong implementation has a bounded audience and context. These are the use cases supported by the current design—not a claim that all of them have been validated at scale.
- Focus timer and app-blocking capabilities live in one Android app
- Nightly reflection and next-day routine planning instead of timer-only productivity
- Health Connect integrations use Android’s native health store where configured
- Optional Google Workspace sync is designed around user-owned credentials (BYOC)
- AI support is documented through Cloudflare Workers/Workers AI and a bring-your-own-key pathway, so do not describe every AI feature as fully on-device
What the system actually does
An overview of key capabilities and system features.
Tapasya focus timer
A strict focus experience, plus a companion web timer, aims to make session completion more deliberate.
App blocker
Accessibility-service based app-window monitoring and time cooldown mechanisms are documented.
Nightly protocol
WorkManager-driven evening reflection and next-day scheduling flow.
Sleep and health context
Health Connect APIs are used for selected sleep, activity, and health-related insights when permissions are enabled.
Math-based alarm
A wake-up flow uses math challenges and controls designed to reduce easy dismissal.
Local intelligence
The app documents MCP-style tool registrations for tasks, calendar blocks, and app-block configurations.
Optional sync
The README describes direct sync through user-controlled Google Cloud OAuth credentials.
Architecture & data flow
Architecture and system flow overview.
Android UI & permissions
Native Kotlin screens request permissions only when their corresponding features are enabled.
Local app state
Room / local preferences keep habits, journal, and routine information on the device by default.
Native system hooks
Accessibility, alarms, WorkManager, and Health Connect connect routines with Android capabilities.
Optional external services
Google Workspace sync uses user-owned OAuth setup; AI prompts may pass through Cloudflare/model infrastructure.
Kotlin, Android SDK, Room, encrypted preferences, WorkManager, Accessibility Services, Health Connect, Google Workspace APIs via BYOC, Cloudflare Workers/Workers AI for assistant calls.
Decisions behind the implementation
Engineering choices and design decisions behind the implementation.
- Use local-first storage for personal habit data instead of requiring a central account database.
- Expose advanced integrations behind feature toggles and permission prompts.
- Treat routine-building as a system workflow: focus, reflection, sleep, and next-day planning are connected.
- Offer optional external integrations rather than forcing every user to connect a cloud account.
Technical Considerations
Key technical details and system scope considerations.
- The public repository is source-available, but its licensing status is not equivalent to a confirmed permissive/open-source license;
- Personal records may stay local by default, but AI requests and optional sync can transmit selected data to third-party infrastructure. Privacy statements should describe those paths exactly.
- Android accessibility and device-admin behavior varies by OS version and OEM. Do not claim an unbypassable blocker across all devices.
- Download totals count repeated release-asset downloads, not unique installations or active users. Site counter and GitHub asset totals are separate measurements.
What I would improve next
The next step is not simply adding features. It is increasing reliability, evidence quality, user trust, and clarity about the boundaries of the system.
Add a tested Android version/device compatibility matrix.
Document exactly what context is sent to the remote AI model and let users disable it.
Publish benchmarks for app launch, battery usage, and focus-session reliability before making performance claims.
Reconcile the public download counter with the GitHub release artifact counter.
Sources & Resources
Project repositories and resource links.