DEV Community: Plant Finder

Rejecting Shoes and Selfies: How We Stop Users from Burning Our AI Vision Tokens

Plant Finder — Thu, 29 Oct 2026 15:59:17 +0000

Within 48 hours of launching Plant Finder on Google Play, we checked our backend telemetry to see what users were scanning.

We expected to see monsteras, tomatoes, rose bushes, and succulents.
Instead, we saw:
A worn-out leather sneaker.
A user’s sleeping cat.
A slice of pepperoni pizza.
A car dashboard.
Dozens of dark, blurry selfies.

When you hand people an app that uses multimodal AI vision to diagnose leaves, human nature takes over: people immediately try to break it.
While this curiosity is completely natural, it creates two major headaches for any mobile developer:

The Hallucination Problem: The AI tries way too hard to find a plant where none exists.

The Financial Drain: Every photo of a coffee mug or a carpet burns real money in visual AI tokens.

Here is how we tackled adversarial non-plant uploads, protected our bills, and stopped our app from diagnosing shoes.
The Sneaker That Had "Severe Root Rot"
General-purpose vision models are trained to be helpful and answer prompts directly.

Early on, if our mobile app sent a photo of a brown leather shoe with the prompt "Identify this plant and its health issues," the AI would genuinely attempt to fulfill the request.

The result? The model returned:
"Species: Ficus elastica (Rubber Tree). Health: 24%. Severe black spot and dehydration on the lower stem."

This was disastrous. If a user tested the app on an everyday object as a joke, seeing the AI confidently hallucinate an entire botanical diagnosis destroyed their trust in the product. If it can't tell the difference between a shoe and a ficus, why would a farmer trust it to identify tomato early blight?

The Token Cost of Human Curiosity
Running high-resolution multimodal vision calls through frontier models like Gemini 2.5 Flash is remarkably fast and capable, but it is not free.
In our first release, roughly 18% of all camera uploads were non-plant objects.

If you have thousands of active users, paying for 18% wasted API calls every single day quickly eats through your operating margins. We were essentially subsidizing people scanning their living room furniture with expensive AI inferences that delivered zero actual value.
We needed a strict gatekeeper.

Step 1: Giving the Model Permission to Say "No"
The first mistake we made was assuming the model knew it was dealing with a plant.
We updated our backend proxy instructions to introduce a strict two-stage verification process inside the prompt:
Stage 1 (The Guardrail): Examine the image purely to verify whether botanical tissue (leaves, stems, flowers, bark, or roots) is clearly present. If the image is not a plant, abort all diagnostic processing immediately and return a strict flag: NOT_A_PLANT.

Stage 2 (The Diagnosis): Only if Stage 1 passes should the model extract foliar pathology, soil pH symptoms, and care recommendations.
By explicitly instructing the model to reject non-plant images on the very first token, we stopped the hallucination loop in its tracks. A picture of a sneaker now simply returns an honest refusal instead of a fake plant name.

Step 2: Designing a Graceful Rejection UI
Catching non-plant images on the server is only half the battle. You also have to handle the user experience on the phone.
If an app abruptly crashes or throws a cold, generic error like "500 Internal Server Error," users assume the app is broken and leave a 1-star review.

Instead, we built an explicit rejection handler in our Flutter camera preview screen:

Clear Feedback: When the server returns NOT_A_PLANT, the app displays a clear, friendly card: "No botanical tissue detected. Please point your camera directly at leaves, stems, or flowers."
Credit Protection: In our virtual token economy ("Leaves"), a scan costs credits. If the system flags an image as a non-plant, we do not deduct their tokens. This prevents honest users who took a blurry or poorly lit photo from feeling cheated.

Step 3: Preventing Deliberate Token Spam
While protecting honest users is essential, you also have to protect your backend against malicious flooding or automated spam scripts.
To prevent bad actors from repeatedly uploading junk images and burning compute:

Server-Side IP Rate Limiting: Our cloud gateway tracks upload frequencies per IP address. If an IP exceeds 15 rapid-fire uploads in a 60-second window, requests are temporarily throttled at the network level.
Progressive Strike Lockout: If a single account or device repeatedly triggers consecutive NOT_A_PLANT rejections in a short period, the app introduces a cool-down timer. This eliminates automated script abuse while leaving normal gardeners unaffected.

What Other Mobile AI Developers Should Take Away
If you are building an AI camera app for food tracking, skin analysis, receipt scanning, or plant care, remember these three rules:
Users will test your limits: Always design your system assuming people will photograph their pets, faces, and surroundings first before testing your actual feature.

Teach your AI to say "I don't know": Models will confidently fabricate answers if your prompt doesn't give them a clear, graceful exit path.
Fail as early as possible: The faster your pipeline rejects an invalid image, the less money you spend on wasted cloud compute.

Project: Plant Finder
Platform: Android (Google Play)
Attribution: Designed by Code vairagi

Why We Stopped Building Just Another Plant Identifier (And What We Learned)

Plant Finder — Thu, 29 Oct 2026 15:37:17 +0000

When we first started building Plant Finder, we assumed the goal was simple: train an AI model to recognize as many plant species as possible from a single photo.

We thought that if a user points their phone at a leaf and the app returns “Monstera deliciosa” with 99% accuracy, the job was done.
We were completely wrong.

After months of real-world testing with thousands of gardeners, students, and plant owners, we realized something critical about how people actually interact with plant apps.

The Reality Check: Nobody Just Wants a Name
Very few people download a plant app just to collect botanical names like trading cards.

In the real world, someone pulls out their phone because something is going wrong:

“Why are the bottom leaves turning yellow while the top looks fine?”
“Are these brown spots caused by a fungus or by overwatering?”
“Do I need to repot this, or is the soil too acidic?”

A botanical name doesn't save a dying plant. A user doesn't just need an identifier—they need a doctor.

Challenge 1: The Yellow Leaf Problem
One of the hardest things in agronomy is that completely different problems look almost identical on camera:
Overwatering causes yellow leaves.
Underwatering causes yellow leaves.
Low nitrogen causes yellow leaves.
High soil pH (nutrient lockout) causes yellow leaves.

If your app simply guesses based on color, you end up giving bad advice that kills the plant.

To fix this, we had to look at how the plant turns yellow. In botany, nutrients move differently through a plant:

Mobile nutrients (like Nitrogen and Magnesium) move upward to protect new growth. If the bottom leaves are yellow but the top is green, the soil is often lacking nutrients or is too acidic.

Immobile nutrients (like Iron and Calcium) cannot move once set. If the newest top leaves are turning pale yellow between the veins, the soil pH is usually too alkaline, locking up iron at the roots.

By asking users to look at both the top and bottom of their plants, we could estimate soil health and pH issues without forcing them to buy expensive soil testing kits.

Challenge 2: The Cost and Speed of AI
Running visual AI on high-resolution leaf photos is computationally expensive. If thousands of users upload photos every day, two things happen very quickly:

Your server bills skyrocket.
Users on slow mobile connections wait 10 seconds for a result and abandon the app.

To solve this, we stopped sending every single photo directly to large language models. Instead, we built a fast visual matching filter directly on our backend.

If someone uploads a common leaf or a plant already verified in our botanical database, the system recognizes the visual pattern instantly. It delivers the answer in less than a second at virtually zero compute cost. The heavy AI models are only called when an unfamiliar or complex problem appears.

Challenge 3: Keeping the App Safe
In the early stages of development, many mobile apps make the mistake of calling AI services directly from the phone.

The problem? Anyone can decompile an Android APK in under two minutes and extract the private API keys stored inside. Once exposed, third parties can abuse your keys and leave you with massive bills.

We migrated all AI interactions completely off the phone and placed them behind our own secure server gateway. The mobile app never touches the AI credentials directly. It simply sends the photo, verifies the request, and receives the diagnostic advice back safely.

What We Learned
Building a successful utility app isn't about using the newest buzzwords or cramming in complex features for the sake of it.
Solve the real pain point: Users care about keeping their plants alive, not just reading Latin names.

Speed matters more than complexity: A fast answer that solves 90% of a problem is better than a slow answer that takes 15 seconds to load.
Security must be built in early: Never leave private keys or sensitive logic inside the mobile client.

Project: Plant Finder
Platform: Android (Google Play)
Attribution: Designed by Code vairagi

Plant Finder: Stress-Testing an AI Plant Identifier App Across 8 Months with 5,000 Botany Students on Android with Flutter published

Plant Finder — Tue, 13 Oct 2026 15:14:39 +0000

The reality of testing Plant Finder, an AI plant identifier app built with Flutter on Android, through 8 months of field testing with 5,000 botany students.
tags: flutter, ai, android, testing

canonical_url: https://plantfinder.store

Most machine learning models for botany perform well on curated benchmark datasets, then fail when deployed on commercial mobile cameras in variable field conditions. An algorithm trained on flat, evenly lit herbarium sheets often struggles when confronted with wind blur, partial insect damage, dew reflections, or juvenile leaf morphology.

When developing Plant Finder, a mobile application built with Flutter on Android, we chose not to rely purely on synthetic vision datasets. Instead, we spent 8 months coordinating with approximately 5,000 botany students to stress-test, ground-truth, and calibrate the engine against living specimens.

Here is an objective look at the app’s functional features and the logistical realities of managing a massive, distributed botanical validation effort.

1. What the Plant Finder Engine Does

Plant Finder was designed to move beyond basic species labeling by combining botanical taxonomy with actionable foliar pathology:

Multi-Organ Species Identification: Uses multimodal vision models to classify plants from multiple structures—leaf lamina, petiole attachments, flower anatomy, and bark textures—across houseplants, agricultural crops, and endemic wild flora.
Foliar Pathology & Disease Diagnostics: Analyzes leaf tissue to differentiate biotic attacks (fungal powdery mildew, bacterial spot, spider mites, thrips) from environmental damage, generating a calibrated 0–100% health score.
Soil pH & Nutrient Lockout Inference: Connects interveinal chlorosis patterns to rootzone chemistry, helping growers spot mineral lockouts and pH drift before crops suffer terminal damage.
Cultivation Reminders & Care Schedules: Translates species requirements into automated watering intervals, light requirements, and customized growth diaries.
Community Hub & Marketplace: Provides an integrated forum and agricultural directory where growers and specialists exchange field diagnostics.

2. The Logistics of Coordinating 5,000 Botany Students for 8 Months

Organizing 5,000 botany students across diverse regional ecosystems sounded ideal in theory, but operational execution presented massive coordination hurdles:

A. The Challenge of Inconsistent Botanical Labeling

Academic taxonomy is rarely uniform in practice. When testing identical specimens across different student cohorts, we routinely encountered conflicting classifications:

Students frequently submitted regional vernacular names instead of formal binomial nomenclature, requiring manual verification against international plant databases.
Subspecies and hybrid cultivars created constant classification disputes, especially within complex families like Araceae, Myrtaceae, and Rosaceae.
We had to implement strict verification thresholds where questionable classifications required confirmation from at least three independent reviewers before entering our evaluation sets.

B. Phenological Drift and Juvenile vs. Mature Tissue

Leaves change dramatically as plants mature. A common problem encountered during the 8-month trial was juvenile foliar confusion:

Immature leaves on young specimens often lacked the definitive margin serration or venation depth of mature foliage.
Cotyledons (seedling leaves) triggered high error rates across standard visual models.
Students had to document plants across full growth cycles—from early seedling emergence to flowering and senescence—to ensure the vision models could handle multi-stage recognition.

C. Camera Hardware and Environmental Inconsistencies

Field conditions are inherently messy. The 5,000 students tested the app across hundreds of different Android device models, exposing hardware-level discrepancies:

Low-end camera sensors washed out subtle yellowing patterns (interveinal chlorosis), causing the model to miss early magnesium or iron deficiencies.
Intense direct sunlight caused reflective glare on glossy waxy leaves (such as Ficus species), which the algorithms initially misclassified as powdery mildew.
We spent months building pre-processing rules to teach the system how to filter out glare, soil backgrounds, and blurred edges before running visual inference.

D. Separating Disease from Physical Damage

One of the hardest tasks for the student reviewers was distinguishing pathogen symptoms from abiotic stress:

A brown, dried leaf tip could indicate low humidity, root rot, chemical burn, or simple underwatering.
Mechanical tearing from wind or handling looks remarkably similar to early bacterial blight on camera.
Over the course of the 8 months, the students cataloged thousands of comparative side-by-side images to train the diagnostic pipeline on the subtle cellular differences between physical tears and infectious necrotic halos.

3. What 8 Months in the Field Proved

Field testing taught us that machine learning models cannot replace practical botanical observation; they require rigorous human-in-the-loop calibration:

Academic Ground-Truthing is Mandatory: Real-world field testing with knowledgeable students eliminated hundreds of edge-case errors that static web datasets never would have caught.
Context Matters More Than Resolution: High-resolution photos are useless if the system does not account for environmental variables like light, soil conditions, and canopy position.
Graceful Failure is Essential: The app needed clear guardrails to tell users when an image was unreadable, out of focus, or not a plant at all, rather than outputting a confident hallucination.

4. Current Status

Following those 8 months of collaborative testing and data refinement, Plant Finder is running in production. The engine supports indoor container gardeners, commercial growers, and field researchers who need dependable botanical classification and foliar health diagnostics on their mobile devices.

The application is available on Android via Google Play, and comprehensive web diagnostic guides and platform documentation are maintained at plantfinder.store.