Why plant identification runs on two different systems

Point a camera at a plant and ask "what is this" and there are two very different ways to answer it. One is species identification: matching leaf shape, growth pattern, and flower structure against a botanical reference to say, specifically, this is a Monstera deliciosa and not a Monstera adansonii. The other is everything downstream of that answer: care tips, condition assessment, answering a free-form question about why a specific leaf is yellowing. FloraFever splits these across two different systems rather than asking one general-purpose model to do both.

Species ID needs a botanical specialist, not a generalist

For the actual identification step, FloraFever uses PlantNet, a system purpose-built for botanical identification and trained specifically on plant reference images rather than general-purpose visual understanding. That specialization matters: two houseplants can look nearly identical to a generalist model while being different species with different care needs, and a botanical-specific system trained on exactly that distinction is more reliable than a general vision model that happens to also know what plants look like.

This is a deliberate build-versus-buy call. Species identification is a solved, narrow problem with mature specialist tools already available. There's little reason to have a general-purpose model relearn something a dedicated botanical system already does better.

Everything else runs on a self-hosted model

Once a plant's identity is known, the rest of FloraFever's AI-assisted features, generating care guidance, answering follow-up questions, don't need botanical specialization so much as general reasoning grounded in whatever the identification step already established. For that layer, FloraFever runs Gemma, an open model, self-hosted on Modal's GPU infrastructure rather than called through a third-party API per request.

Self-hosting this layer is mostly a cost and control decision. Care-guidance generation is a high-volume, relatively low-complexity task compared to species ID, exactly the kind of workload where paying per-API-call to a hosted model adds up fast, and where owning the inference stack means FloraFever can tune latency and cost independently of any one vendor's pricing changes.

Two systems, one clear boundary

The architecture keeps a clean boundary: PlantNet answers "what species is this," and everything after that, framed by the answer PlantNet already gave, runs through the self-hosted model. Neither system is trying to do the other's job. The specialist handles the narrow, high-stakes classification step where being wrong means bad care advice for the wrong plant; the general model handles the broader, lower-stakes layer where flexibility matters more than domain specialization.

That split is also what makes each half independently replaceable. If a better identification service comes along, swapping it doesn't touch the care-guidance layer, and vice versa, since the two were never coupled together as one monolithic "AI feature" to begin with.

See how identification fits into the rest of the app on FloraFever's product page.