GardenPulse: a method-agnostic garden companion built on Expo and Firebase

One app for soil, hydro, container and indoor growers

GardenPulse is a mobile app for people growing plants at home, and its central bet is that the growing method changes the advice. The README describes it as method-agnostic: windowsill herbs, balcony containers, hydroponic setups and large collections of houseplants each get their own care schedule and guidance rather than one template applied to everyone. Around that sit location awareness, live weather, camera diagnostics and a layer of gamified community features.

The audience is consumer gardeners and the developers building for them. The project is written in TypeScript on Expo SDK 54.0.35 with React Native 0.81.5, uses React Native Paper for its UI component set, Zustand for state and TypeScript at about 5.9.2, so a team already in the Expo ecosystem can read the whole codebase without a translation layer. The package entry point is expo-router/entry, which means navigation is file based rather than configured through a route table.

Firebase holds the account and the garden records

The backend is Firebase, at version 12.x in the badge and ^12.14.0 in the dependency list, covering Auth, Firestore and Storage. Storage is the interesting part for an offline-capable app, because the README promises a privacy-first, offline-capable architecture and the dependency list includes @react-native-async-storage/async-storage at 2.2.0 for local persistence. Firestore holds the shared record of what is planted, and Auth ties it to a person.

The repository layout shows a conventional Expo project with the usual separation: app/ for routes, components/ for UI, services/ for backend and API calls, store/ for Zustand state, constants/ and types/ for shared definitions, plus App.tsx and index.ts at the root. There is also a small collection of files that describe the project as much as they implement it: GARDENPULSE.md, INSTALL.md, AGENTS.md, CLAUDE.md, a .docs/ folder with the product specification, and Architecture.drawio for the diagram. generate_components.py at the root suggests some of the UI scaffolding was produced by a script rather than typed by hand.

On-device diagnostics versus a Gemini key in the client bundle

This is the part of the project worth reading twice, because the README and the environment template tell different stories. The feature table claims Gemini Vision Diagnostics run entirely on device and that photos are never uploaded to the cloud. The .env.example file, on the other hand, labels a section GOOGLE AI STUDIO (Gemini API Layer) and annotates the key with the comment Used for Leaf Diagnostics, Vision scanning, and Multimodal chat.

Both statements can be true only if the code has two paths, and the documentation does not say which one a given user hits. The on-device description also names Google AI Studio in the technology stack table, which is a cloud service, so the phrase on-device ML in the feature table is doing some work.

The practical consequence is about your key, not your privacy policy. Anything prefixed with EXPO_PUBLIC_ ends up inside the shipped client bundle, so the Gemini key would be readable by anyone who installs the app. The template itself warns that in Expo SDK 49 and later, variables accessed in client code must carry that prefix, which leaves no room for a server-held secret in this architecture.

Hardiness zones, GPS and a weather API that moves your schedule

Location and weather are what turn a static care guide into an adaptive one. The README describes GPS and network location for hyper-local recommendations and regional pest alerts, automatic USDA Hardiness Zone detection that filters the plant database to species that can survive in your region, and the OpenWeatherMap One Call API 3.0 for temperature, humidity, precipitation and UV index. The stated effect on the schedule is concrete, for example skipping watering when rain is forecast for tomorrow.

Scheduling also leans on astronomy and the clock. Sunrise and sunset tracking schedules grow tent light cycles and outdoor watering relative to solar events, and the engine is timezone aware with daylight saving handled automatically plus travel-friendly reminder controls. Analytics wrap the same data into a Garden Health Score that tracks eight metrics, of which the README names soil moisture, light exposure, pH stability and growth rate, and into adaptive growing profiles such as Low-Light Apartment, Sunny Balcony, Hydro Tent and Raised Bed.

One feature deserves a second look because it is unusual for a hobby app. The Cemetery Log keeps a historical record of failed grows, and the stated purpose is identifying root causes such as pH spikes and root rot over time.

Ads are designed into the dosing and export moments

GardenPulse is not a free hobby project, and the README is unusually direct about it. A monetization table lists four ad formats with their triggers, including a high-intent interstitial triggered at dosing calculation and export moments with a target eCPM of $25 to $45 for tier 1, contextual native ads styled as Garden Tips inside the activity timeline, and rewarded videos that grant access to PDF garden plans, compliance logs and advanced calculators. A Supporter Badge costs $2.99 as a one-time purchase and removes interstitials only.

That last detail matters for anyone planning a business model on top of this code. A paid badge that removes only the interstitials leaves native ads and rewarded video in place, so the paid and free experiences are not cleanly separated.

The dependency list confirms the implementation: react-native-google-mobile-ads at ^16.3.3. The README also states that core tools are 100% free, forever, which sits in a slightly awkward position next to the interstitial and rewarded video triggers.

Running it: the expo scripts and the EXPO_PUBLIC_ variables

The install notes live in INSTALL.md rather than the README, so the README itself carries no installation command. What the package manifest gives you is the run surface, with four scripts:

  "scripts": {
    "start": "expo start",
    "android": "expo run:android",
    "ios": "expo run:ios",
    "web": "expo start --web"
  },

There is a web target as well as the two mobile ones, and expo-dev-client plus eas.json in the tree point to a native build workflow through Expo Application Services rather than a pure Expo Go workflow. The app scheme is gardenpulse, which is what deep links and the QR scanner feature would target.

Configuration is driven from the .env.example template, which expects one secret per service:

EXPO_PUBLIC_APP_ENV=development # Options: development, staging, production
EXPO_PUBLIC_FIREBASE_API_KEY=your_firebase_api_key_here
EXPO_PUBLIC_GEMINI_API_KEY=your_gemini_api_key_here
EXPO_PUBLIC_GOOGLE_MAPS_API_KEY_ANDROID=your_google_maps_android_key

Seven Firebase variables cover Auth, Firestore, Storage and messaging, and the template recommends separate Google Maps keys for iOS and Android so they can be restricted by package name. That recommendation runs into the EXPO_PUBLIC_ prefix rule, since a value with that prefix is compiled into the client.

A proprietary licence and no tagged releases

The licence is the decisive fact for anyone planning to build on GardenPulse. The README badge reads License Proprietary, package.json sets "license": "UNLICENSED" and also sets "private": true, and the repository listing classifies the licence as Other because GitHub cannot categorise the custom LICENSE file. The LICENSE file in the tree is the text that governs, and nothing in the documentation grants redistribution rights.

Two other facts belong in the same paragraph. The repository has no GitHub releases, so there is no tagged version whose dependency set anyone validated for you, and package.json carries version 1.0.0 with the whole dependency tree pinned by package-lock.json. The last push was on 2026-06-30, and the topics list mentions an MIT licence tag while the badge and the manifest say the opposite, which is worth resolving before you copy code from the tree.

Editorial conclusion

Adopt GardenPulse if you are building a consumer gardening app and want a working reference for method-aware care schedules, hardiness zone filtering and camera-driven plant identification on Expo. Do not adopt it as an open source base you can relicense, and check the licensing file before shipping anything derived from it, since the README badge labels the project proprietary, package.json sets the licence to UNLICENSED and the repository listing classifies the licence as Other. Verify three things first: whether leaf diagnostics actually stay on the device, since the environment template points the Gemini key at leaf diagnostics while the feature table claims photos are never uploaded; whether you want AdMob interstitials inside dosing and export flows; and whether Firebase, OpenWeatherMap and Google Maps keys are acceptable in a client bundle. The last push was on 2026-06-30 and the repository has no GitHub releases.

Frequently asked questions

Official sources

1. AhmadHassan-BTed/GardenPulse on GitHub
2. Issues
3. README