Andrews DeanContext
An adult child living away from an aging parent, common across urban India, wants one thing: to know their parent took their medicine without having to call and check. CareCircle is a medication-reminder app built around that pair rather than around the parent alone. The caregiver holds the account and configures everything; the parent's entire interaction is a text message they can tap or reply to, with no login and no app to install.
I'm building it by directing Claude Code as the implementation partner. I act as product owner, architect-in-the-loop, and release gatekeeper, applying the same discipline I'd use managing an engineer to an AI agent instead.
The problem
Every medication-reminder app on the market is built for the person taking the medicine, and assumes they're comfortable with an app: streaks, red "missed dose" badges, guilt-driven UX. That's the wrong design for a 70-year-old parent who may own a basic phone and has no interest in installing anything, when the person who actually needs the peace of mind is their child.
The harder problem sat one level up, in how the product gets built at all. Directing an AI agent on a health-adjacent product means the mistakes that matter aren't cosmetic: a signing key treated as disposable when it's actually permanent, an accessibility rule that quietly regresses, a reminder that fails on the exact cheap Android phone the target user owns. Catching those needed an enforced process, more than good instincts.
Constraints
- A parent who may never install an app. Confirmation had to work by tapping a link or replying to a text, with zero login and zero data connectivity assumed on their side.
- Reminder delivery is a health-adjacent failure mode. The whole product exists to prevent exactly the outcome a missed reminder represents.
- Target hardware is the cheap end of Android — Xiaomi- and Realme-class phones, where aggressive battery optimisation kills background processes and silently drops on-device notifications.
- No shortcuts on health data. India's DPDP Act applies, and the parent, who never creates an account, is still a data subject.
How I'm directing the build
I wrote the spec and the gates before any code, and I've held both without exception. Nothing gets built until a written plan is approved. Nothing merges without an explicit go-ahead. Every meaningful change, a dependency, a piece of local infrastructure, the design system, went through its own plan, build, on-device verification, and status update before the next one started. Slower per step, and worth it: at any point there's a written record of exactly what state the project is in and why, rather than a probably.
The AI surfaces real forks in the road, and making the call is my job, not a rubber stamp on its first answer. When the build tooling auto-generated a signing key for the Android app and framed it as a disposable dev-only artifact, I corrected that immediately — that key is the app's permanent identity if it's ever published, and losing it would make future updates impossible. When a styling library's stable release had contradictory guidance on compatibility with the animation library underneath it, I chose to pin the known-good version and verify on a real phone rather than gamble on a preview build, with a standing rule that a failure there gets escalated to me, never silently worked around.
Reliability got engineered around the actual failure mode of the hardware people in this market actually own — a flagship phone's happy path was never the target. Reminders are scheduled server-side and delivered by SMS, never as an on-device notification, because the phones this product targets are exactly the ones that kill background apps to save battery. It's a slower, less fashionable choice than a native push notification. It's also the one that survives contact with the device the parent actually owns.
Four purpose-built AI review roles sit in the process alongside me now: one checks database security policies, one checks UI changes against accessibility rules, one checks any diff against the full rule set before a merge, and one reconciles the three different senses of "done" that a mobile build has — merged, published as an instant update, live in an app store — so they can't quietly drift apart.
Where it stands
This is a foundation-phase build, and I'd rather say that plainly than let a portfolio page imply otherwise. What's real today: the app running on a real Android phone against a fully local backend, the complete design system verified on-device in light and dark, the cloud build pipeline proven with a real successful build, and the governance scaffold, written rules, phase tracking, four AI review roles, already exercised rather than just planned. Authentication, the data model, the reminder scheduler, and the actual caregiver screens are the next phases, each gated the same way everything before it was.
What I'm watching for next
The written success bar is specific on purpose: 10 to 15 real caregiver-parent pairs using the app for two weeks, reminder delivery around 98% or better, and caregivers who'd be genuinely annoyed to lose it. Hitting that number is what earns the right to build the v2 feature list and turn on monetisation, both of which already exist and are switched off. Missing it means fixing the core loop before adding to it. Deciding that bar before a single screen existed is the part of this process I trust most.