A Hacker News post from a developer who killed every houseplant they owned is building an app to fix the problem, and the technical choices behind it are more interesting than the premise suggests. GrowBook is a Flutter-based plant care tracker designed around a single conviction: an app whose job is to remind you to do something at home should work without an internet connection. The developer, posting as gongshaojie12, is building it in public and plans to document the failures as much as the successes.
Why another plant app
The developer tried existing options before building their own. The well-designed ones turned out to be subscription walls with a plant illustration on top, where adding a second plant required paying. The free alternatives drowned users in feeds, shops, and virtual currencies. Almost all of them assumed constant connectivity, which is a strange requirement for an application whose primary function is a timed reminder about something sitting in your living room.
The specific failure mode that triggered the project is mundane but real: watering every plant on the same day because there was no way to track which plant wanted what. Half the collection rotted, the other half dried out. The developer wanted per-plant schedules for watering, fertilizing, and pruning, with actual photos of each specific plant rather than stock images of the species. The list of requirements was small and boring, which is exactly the point.
Offline-first architecture
Every piece of data lives in a local SQLite database using Drift, a type-safe Dart library for database access. The app is fully functional before the user has ever seen a login screen. Cloud sync exists as a feature you opt into, not a wall you climb over to use the app at all. This architectural decision affects everything downstream: reminders fire reliably even with no internet, and the app survives phone reboots without losing its state.
The choice of Drift over raw SQLite or other Dart database packages reflects a desire for type safety and migration support. Drift generates Dart code from SQL definitions, which means schema changes are caught at compile time rather than crashing at runtime on a user's phone. For a solo developer building in public, that kind of safety net matters more than squeezing out marginal performance.
Flutter, Android first
The app is built with Flutter and targets Android first. This is a pragmatic choice given the developer's solo status and the target audience. Android's notification system is notoriously tricky to get right, especially for reliable background scheduling, and the developer has already flagged this as one of the early pain points they plan to document. Flutter's cross-platform promise is appealing, but shipping a working Android app before worrying about iOS keeps the scope manageable.
The developer also mentioned ripping out and rebuilding an AI plant identifier, suggesting the feature set is being shaped by what actually works rather than what sounds impressive in a demo. The current feature list is deliberately minimal: a list of plants with real photos, per-plant schedules, and reminders that fire offline without an account.
Building in public with honest accounting
The developer's status report is refreshingly blunt: zero users, zero revenue, and a plant survival count that is suspiciously healthy because the developer does not count themselves as a success case. The plan is to post about specific technical problems as they arise, including the week lost to Android's notification system, a light sensor Flutter refused to read, and the plant identifier that had to be rebuilt from scratch.
This kind of public development log is useful beyond the project itself. The specific technical failures, the decisions about what to cut, and the tradeoffs between offline capability and cloud features are patterns that apply to any solo developer building a utility app. The plant care domain is the vehicle, but the interesting content is the engineering process and the constraints of building something small and reliable without a team or a budget.
The developer closed by asking what existing plant apps get wrong for people who actually use them, framing the project as a response to real user frustration rather than a technical exercise. At zero users and zero revenue, the app is early, but the architectural opinions are clear and the plan to document the rough parts of solo development is a commitment that is easy to respect.