The Product Decision Behind “When Android quietly kills a plant reminder” in GrowBook
A tiny utility app still needs a clear opinion about how the work should happen.
A plant reminder has one job: appear when the plant needs attention.
Why I made the call
GrowBook explains why it asks for notification access before showing the system prompt. It checks the relevant settings, saves schedules locally, and rebuilds reminders after a reboot or app update. When the operating system refuses an exact time, the app needs to say so instead of pretending everything is fine.
What I am watching after launch
There is still no universal switch that defeats every battery manager on every Android phone. I would rather be clear about that limitation and guide people to the right setting than promise a reminder that may never arrive.
A reminder that admits it needs one more system setting is better than a silent reminder that never appears.
I am tracking whether people use this twice, not whether they say the screen looks nice.
GrowBook on Google Play: https://play.google.com/store/apps/details?id=com.yuntai.growbook
This is great work — what's the biggest thing you'd do differently if you started over?
How did you decide this was worth building in the first place?
The original spark came from a Reddit post I can’t find anymore. Someone described the same basic problem I had: keeping track of when each plant was last cared for.
I’d normally go back to those communities and ask more questions, but my account is currently blocked from posting in some of the relevant subreddits. So I don’t consider the idea validated yet. Building GrowBook was the fastest way to put the idea in front of real users and see whether the problem extends beyond that one post and my own experience.
What made you pick this stack over the alternatives?
I chose Flutter because I’m building this mostly solo and wanted one codebase for Android and iOS. Drift was the more important choice: plant records and schedules have to work without an account or connection.
Riverpod keeps the local state and notification logic manageable, while Supabase sits on top for optional sync and family sharing. The app never waits on the cloud for a core action.
What made you pick this stack over the alternatives?
Tracking whether people come back twice is the right instinct, but that number cannot see the failure you are worried about. Somebody whose reminder never fired and somebody who simply did not need one both look like a person who did not return. The number that separates them is scheduled versus actually delivered, logged on the device: you set two hundred reminders this week, how many fired within a few minutes of their time. Bucket that by manufacturer and you will find out quickly whether this is an Android problem or a Xiaomi and Huawei problem, which are very different things to tell a user.
That’s the measurement gap. GrowBook can inspect pending notifications, permission state, exact-alarm access, and battery exemptions, but it can’t currently confirm that Android displayed a particular reminder.
Since the Dart process may be dead when the notification fires, I’d need to record the scheduled and fired timestamps on the native receiver side, then compare them when the app next opens. Bucketing that by manufacturer would be especially useful for Xiaomi and Huawei, provided any reporting is anonymous and opt-in. That would tell me far more than another app open.