Fleurish

An app rooted in discovery! Scan the flora on your daily excursions, identify it, and add it to your ever-expanding garden. Compete with your friends to see who can have the most blooms!

Comment 1

Inspiration

We walk past hundreds of plants every day, yet we can name almost none of them! At the same time, apps like Duolingo have shown that streaks and friendly competition can increase daily app activity for
almost anything. We wanted to point that energy toward the great outdoors: what if noticing nature felt like a game you could play with your friends? Fleurish turns every walk into a treasure hunt, where the
collectibles are already growing on your street—yours for the scanning!

What it Does

Fleurish is a plant-spotting social app. Point your camera at any plant and AI will identify it in seconds, returning its name, a confidence score, and care tips. Each find is saved to your personal garden, extends your daily streak, and appears in your friends' feed where they can like it. A leaderboard tracks who has "bloomed" the most.

Fleurish also includes a Plant Doctor: photograph a sick plant and Gemini will diagnose the issue, generating a step-by-step treatment plan.

Technical Deep Dive

The most important design decision was pushing game logic into the database rather than the client. Saving a find triggers a chain of Postgres triggers: the streak recalculates, a feed event is published to friends, and a PostGIS location point is recorded, all server-side. The app cannot get the rules wrong because it never runs them.

The identification pipeline resizes each photo to 1024px, base64-encodes it, and sends it to a Deno edge function that calls the Plant.id API, with distinct handling for "this is not a plant" versus service failures. The Plant Doctor sends photos to Gemini 2.5 Flash with a structured botanist prompt and receives typed JSON back: diagnosis, confidence, and an action plan. Every table is protected by Row Level Security, so visibility rules (public finds, friends-only feeds, own-folder photo uploads) are enforced at the database layer rather than in application code.

How We Built It

Our team of four split into two frontend and two backend developers, building in parallel and integrating continuously.

Frontend:

  • React Native with Expo (SDK 54) and expo-router for file-based navigation
  • Custom design system with its own typography, color palette, and theme
  • Camera capture, gallery import, location tagging, and date logging via Expo modules

Backend:

  • Supabase: Postgres with PostGIS, Auth, and Storage
  • Deno edge functions for AI integrations and privileged writes
  • Database triggers for streaks, feed events, and geo-stamping
  • A typed logic layer connecting each screen to live data

Challenges We Ran Into

Expo version churn. Midway through, we discovered the file system API we had built on was rewritten between SDK versions, and functions like readAsStringAsync no longer existed. The fix was small once diagnosed, but it taught us to check versioned documentation before writing code against any Expo API.

Version control at speed. We hit a point where source control showed 34,000 untracked files, caused by renaming a project folder on Windows while the dev server still held file locks. We also worked through a reverted merge and rebuilt our frontend history on a recovery branch.

Parallel development, single integration window. With frontend and backend built simultaneously in 12 hours, the real test came when the UI met the live backend: ambiguous foreign key references, RLS policies silently returning empty results, and an unstable tunnel connection all surfaced at once.

Seamlessly integrating the front end. Many graphics and vectors were made separately and exported, and the text had to be formatted to fit certain size constraints. Atop of that, there were many different screens to design, and we wanted to stay in-theme with the light, airy colors and photos we chose to make our backgrounds.

Accomplishments That We're Proud Of

  • A complete capture-to-feed loop: photo, AI identification, storage upload, and social feed, working end to end on real devices
  • Streaks and feed events that maintain themselves through database triggers
  • Two AI integrations (Plant.id and Gemini 2.5 Flash) with graceful error handling
  • Security enforced at the database layer with Row Level Security on every table
  • Four people shipping a shared codebase in one day without stepping on each other
  • Sleek, accessible, yet customized UI

What We Learned

  • AI features are only as good as their error handling; "this isn't a plant" and "the service is down" need completely different responses
  • Putting invariants in the database makes an entire class of client bugs impossible
  • How to diagnose repository state under pressure instead of guessing
  • Communication beats code: our biggest speedups came from five-minute "who's doing what" conversations

What's Next for Fleurish

  • Plant collections, lists, and rare-plant badges
  • Push notifications for likes and friend requests
  • Making the Plant Doctor conversational for follow-up questions
  • Greater emphasis on location tracking, in order to alert all nature lovers of nature trails and botanical parks they might have not been aware of.

Built With

  • React Native
  • Expo
  • TypeScript
  • Supabase
  • PostgreSQL
  • PostGIS
  • Deno
  • Plant.id API
  • Google Gemini 2.5 Flash
  • Git/GitHub

Built With

+ 6 more
Share this project:

Updates