AI Plant Identification App: Jadi-Booti Solo Explained
See how Jadi-Booti Solo combines AI plant identification, outdoor quests, and a nature journal—and what its design gets right about using tech to get outside.
Can an AI App Get You to Put Your Phone Down? Inside Jadi-Booti Solo
Most plant ID apps start the same way: point your phone at a leaf, snap a photo, and wait for an answer. Jadi-Booti Solo flips that script with a different question - can a screen actually help you look up?
This project is a nature exploration app made for Hacktoberfest's Open-Source AI Challenge, specifically "Touch Grass." It combines AI-assisted plant identification with outdoor missions and a journal for saving observations. The point isn't to keep you scrolling through plant facts. It's to help you notice what's growing on a campus path, in a local park, or along a neighborhood sidewalk - and then get back to the walk.
That's a solid goal, but it also sets up a real design test. If the app demands constant attention, it undermines itself. And if the AI sounds more certain than it should, it can turn a curious moment into a safety issue. Here's how Jadi-Booti Solo is described, what its technical choices make possible, and what still needs to work before an AI plant guide belongs in an outdoor routine.
A nature app with a different job
A lot of mobile products are built to make the next interaction feel effortless. A notification pulls you back, a feed gives you something else to read, and the interface is always nudging you toward another tap.
Jadi-Booti Solo claims a different standard: the phone helps you start exploring, but the outdoors should be the main event.
That distinction matters, because "use technology less" isn't a feature by itself. The app has to make the alternative - the actual walk - easier or more rewarding. In this case, that means helping you spot a plant, learn a little from it, and save what you noticed without turning a short stroll into a prolonged screen session.
From identification to curiosity
The app's core interaction is simple. You take or upload a photo of a leaf, flower, or bark. The app returns a possible identification plus supporting details - like a common name, botanical name, visible characteristics, and a confidence score. The project description also mentions plant stories and audio narration in Hindi or English.
That framing is better than presenting the AI answer like a final label. If the interface shows both a confidence score and the visible traits that informed the guess, it gives you something to compare against what you can actually see. Ideally, the question shifts from "What is this plant?" to "What in the image led the app to this suggestion?"
Still, there's a limit here: a photo-based guess isn't the same as a verified identification. Lighting, season, plant age, and regional variation can all change what a plant looks like. Different species can look surprisingly similar, and the same species can look very different across growth stages. So even if the app makes exploration easier, the model output should be treated as a starting point - not proof.
Missions give the user somewhere to go
Jadi-Booti Solo also describes "Nature Quests," which are physical prompts meant to nudge you toward something specific outdoors. The project lists "The Tri-Leaf Hunter" as an example mission. The source doesn't provide a full quest catalog, but the logic is clear: a prompt gives a walk a bit of purpose.
That can work better than generic encouragement to "explore." A student on campus might suddenly notice a tree they've walked past a hundred times. Someone out with a dog might look for different leaf shapes around a neighborhood park. The activity should be doable without special gear, and the app can help make recording what you find feel worth your time.
The bigger design question is flexibility. If a mission depends on finding one exact species, it can frustrate people when that plant isn't local or isn't in season. Better prompts would focus on observable traits - leaf shape, texture, color, or habitat - and offer alternatives. The goal should be attention, not a scavenger hunt that ends the moment you miss a specific target.
The journal turns a one-off walk into a record
A nature journal gives you a reason to come back to what you've seen, instead of treating each outing like a one-time moment. The project describes saving plant entries, voice notes, and optional location-based memories. Those details can capture context a single photo can't: where the plant was found, what the weather was like, or what the observer noticed in the moment.
But location features need restraint. A precise location can be useful for a private journal. It can also expose sensitive places or routines if people share entries. The app should make location optional, clearly explain what's stored, and avoid exposing private observations by default. That's a product decision, not just a privacy policy detail.
How the AI and app experience fit together
The project's description names Meta's Llama 3.2 Vision, specifically the 11B vision model, run through Groq's inference service. The basic flow is familiar: take a photo, send it for analysis, and show the result in the app. The repository also describes a web frontend, an Express backend, curated plant data, voice-note support, and progressive web app features.
That said, these are implementation details reported by the project, not proof that every feature is already reliable in the deployed version. The author explicitly notes that deployment and the AI features are still being worked on. That matters, because features can exist in code but behave differently under real network conditions - or in a public demo.
What a vision model can - and cannot - do
A vision model can look at what's visible in an image and generate a plausible description. That's useful for educational exploration, especially if the response helps a user notice details they might otherwise miss. But it doesn't automatically mean the system has confidently identified a plant or validated every claim it makes.
For a plant identification result, the interface should separate different kinds of output:
- Visual observations: details the model believes are visible in the photo.
- Candidate identification: a likely name, presented as a possibility rather than a certainty.
- Reference information: facts drawn from a curated (or otherwise traceable) source.
- Safety guidance: a clear warning not to eat, handle, or use a plant based only on an AI result.
This separation matters because smooth, confident language can still be wrong. A confidence score helps, but it shouldn't be treated like a calibrated probability unless the system has actually been evaluated that way. "The model is 90% confident" only means something if that number has a defined, tested meaning.
The project's safety uncertainty notice is a step in the right direction. If this is a public-facing app, the warning should appear where users might act on the answer - not tucked away in wording you only see after the fact. And users shouldn't use the app to decide whether a plant is edible, medicinal, or safe to touch.
Why narration can help outside
Audio narration fits the idea of spending less time staring at the screen. A short spoken summary can deliver a plant story or observation without pulling you away from your surroundings. Voice notes can do the opposite: instead of typing, you record what you noticed and then keep walking.
The details still matter. Audio should be optional, easy to pause, and comfortable at a reasonable volume. In a busy park - or near traffic - headphones can also reduce your awareness of other people and hazards. So the app shouldn't assume every outdoor moment is the right moment for audio playback. Accessibility also means offering text alternatives, captions or transcripts, and controls that work for people who can't use voice input.
A good rule is to keep the phone interaction short and deliberate. Take a photo, review a concise result, save a note if you want, then put the phone away. If narration turns into a long sequence of screens, it's recreating the exact attention problem the app claims to avoid.
The practical engineering trade-offs
The described stack - HTML, CSS, and JavaScript on the frontend, with Node.js and Express for backend routes - is pretty standard. That isn't automatically a bad thing. For a small project, a familiar stack can make it easier to build a working interface, expose an API, and pull in contributors without forcing everyone to learn a completely new framework first.
Where things get more delicate is at the edges: the frontend has to hit the right backend endpoint, the backend has to talk to the model provider, responses need to be handled when they're slow or malformed or unavailable, and the deployed service has to protect its secrets from ending up in browser code.
The author notes that moving from local development to deployment surfaced connection problems between the frontend and backend. That's common. More importantly, it's the kind of problem you should treat as core engineering - not as something to clean up once everything else is "done."
Keep model calls on the server
If you're using a hosted inference service, API credentials generally should stay on the server. If you put a provider key in client-side JavaScript, anyone who inspects the page can grab it.
An Express backend can act as the controlled boundary: it validates requests, keeps credentials private, applies limits, and returns only what the interface needs.
That same boundary is also where you handle operational issues. For example, the app can return a clear timeout message instead of leaving a spinner running forever. It can limit image size, reject unsupported formats, and avoid sending the same image repeatedly if someone taps twice. These controls matter when requests cost money or hit provider rate limits.
Design for failure, not just the demo path
A real plant photo taken outside can be huge, blurry, poorly lit, or crowded with background distractions. Mobile connections can drop between capture and response. The model service can also be temporarily unavailable. Those aren't rare corner cases - they're normal conditions.
A resilient flow should tell users what's happening and preserve their work. If an identification request fails, the photo or journal entry shouldn't just vanish without explanation. The app can offer a retry, let users save the observation without an identification, or show locally available curated information.
This is where the journal and AI features should stay loosely coupled: one should still be useful even if the other is temporarily offline.
Progressive web app features might make the app feel more native on supported devices, but they don't automatically make everything work offline. Someone has to decide what gets cached, how stale data is handled, and whether journal entries remain on-device until a connection returns. Those choices affect reliability and privacy.
Measure the right thing
For this product, session length isn't a great primary success metric. A long session might mean someone is learning - or it might mean they're stuck trying to get a result.
More useful signals might include whether users complete a quest, save an observation, come back to their journal later, or actually use the app in low-connectivity situations.
Even then, context matters. Just counting saved photos doesn't prove the app increased outdoor activity. A lightweight user study (or even a simple feedback prompt) can reveal whether quests change what people notice - and whether the AI explanation is understandable. For an early project, honest feedback from real walks is often more valuable than analytics that can't answer the main question.
What to improve before relying on an AI plant guide
The most interesting part of Jadi-Booti Solo isn't tied to any single model. It's the attempt to use AI as a small bridge between a person and their surroundings. The concept works best when the app encourages real observation, clearly communicates uncertainty, and doesn't overstep.
There are also real constraints to respect. Plant information varies by region, and common names can refer to different species. Cultural or ecological uses require careful sourcing and context; a model-generated summary shouldn't blur the line between "here's a story" and "here's medical advice." A curated collection can improve quality, but it takes ongoing effort to keep coverage accurate and up to date.
Build trust into the result
A good result screen should help users judge what they're seeing without pretending the model knows more than it does. In practice, that means showing the suggested identification alongside visible features, uncertainty, and a straightforward safety notice. When possible, it should link to a reliable botanical reference or clearly describe where the curated data comes from.
It should also be clear about what happens to an uploaded image. Is it sent to an external inference provider? Is it stored by the app? Can it include location metadata? Those details aren't minor for a camera-based product. People may share photos that include faces, homes, or other identifying information in the background. Clear explanations help users make informed choices.
Make regional coverage a community task
The project invites contributions for regional plants, accessibility improvements, and new nature challenges. That's a good open-source direction, but community contributions work best when the project defines how changes are reviewed.
A plant record needs more than a name and a photo. It can benefit from a scientific name, region, source, date checked, and a note about uncertainty or seasonal variation.
A simple contribution template can make review easier and reduce the risk of treating an unsourced story like established botanical information. Local contributors can add real value, while maintainers can still separate expert-reviewed facts from suggestions that need verification.
The same logic applies to quests. Community members can propose missions that fit local parks and seasons, but prompts should be safe and accessible - and possible without disturbing wildlife or damaging plants. A good outdoor app encourages observation, not specimen collecting or entering restricted areas.
A practical checklist for the next iteration
If you're building something similar, it helps to nail the basics before layering on more AI features:
- Make the primary outdoor task understandable in one screen.
- Label model output as a suggestion and explain uncertainty in plain language.
- Keep safety guidance right next to any plant information that could be misused.
- Protect provider credentials and handle timeouts, bad images, and rate limits.
- Let users save observations even when AI identification isn't available.
- Make location sharing and image retention explicit and optional where possible.
- Test the full flow on real phones, outside, on normal mobile connections.
- Ask whether the app helped people notice more - not just whether they tapped more.
That's the difference between a demo that feels good and a tool people can trust. A demo proves the happy path can work. Field testing shows what happens in real light, real connections, and when the plant doesn't match what the model expects.
Conclusion: Let the technology point outward
Jadi-Booti Solo is built around a good product constraint: the app shouldn't become the destination. AI identification, audio, quests, and journaling only help if they bring you closer to what's actually in front of you - and if they're honest about what the technology can't verify.
The project is still a work in progress, especially around deployment reliability and the AI features. That's not a reason to dismiss the idea. It's a reason to judge it based on the full field experience, not just the feature list. If you want to look at the implementation, start with the GitHub repository and the original project submission.
And if you're reading this on your phone, try the smallest version of the concept: step outside, notice one plant you'd normally walk past, and look at it before looking it up. The app should support that moment - not replace it.