Mobile app development. Building Flori around plant care

A plant photo is an easy opening for a mobile app. Flori also needs to help its owner decide what to do after the result appears. That second visit shapes the product far more than a polished identification screen.

We are building Flori as a mobile and web product for plant care. Development is ongoing. The website accepts early-access registrations, and the interface shown here comes from the development version. For a team commissioning an app, the useful part of this story is how those screens connect to a recurring task.

Start with the task that brings someone back

Flori began as an idea at Startup Weekend Žilina. INOVIA co-organised the event. We collaborate on the product with Samuel Wittlinger. The team photograph below was published by Startup Weekend Žilina.

An event gives an idea a deadline and a reason to exist outside a notebook. Sustained product work asks a different question. Once the app has identified a plant, why keep it installed? In Flori, the collection gives each plant a home in the interface. Care plans and reminders connect that record to something the owner can do. A journal keeps the photographs and observations that would otherwise be scattered across a phone.

This is worth deciding before estimating a build. A service app might earn its return visit through an open request. A plant app has to remain useful while the plant changes. The camera can introduce the product, but the continuing task needs its own design.

Design the empty collection before filling it

A screenshot full of healthy plants tells little about a new user’s experience. An empty collection needs to explain how to add a plant. An upload has to show that work is happening, and a failed attempt needs a route back into the task.

These states belong in UX/UI design, alongside the screens intended for presentation. In Flori, shared components carry familiar actions from the collection into a plant detail. Design tokens keep spacing and typography consistent as those components change. Colour helps establish the product’s character. A readable label still has to do the work of explaining an action.

Our October 17, 2026 inventory counts 43 mobile routes, including dialogs. It excludes layouts and technical experiments. The app has five main navigation sections, with eight scenes in its onboarding.

The flora index holds 4,119 unique entries. The case study documents how we counted them. A species record does not mean a complete care plan is available for that plant.

Motion should make a transition understandable

Flori’s onboarding uses animation and a mascot. A moving panel can also explain where a dialog came from and how to return to the screen beneath it. The video follows the animated introduction in Flori’s web version, so you can see how the scenes connect.

We use React Native with Expo and TypeScript for the mobile app. We build the mobile interface animations with Reanimated. The web uses Next.js, with PostgreSQL for data. These choices give us tools for implementation, but they do not decide whether a transition is useful. An effect that holds up a routine action needs another pass.

Points and badges are part of the gamification work. We want feedback that relates to caring for a collection, rather than an unrelated reason to tap a button. There is no retention result to report at this stage. That will require observing how people actually use the product, after the visual work has become ordinary to them.

Give an AI result somewhere useful to go

Plant identification is the start of a workflow. The result needs a relationship to the saved plant and to the next action its owner can take. When we plan an AI integration, that relationship matters as much as displaying an answer.

Flori’s plant index and its care content have different scopes. Having a species name in the database does not establish the conditions of an individual plant in someone’s flat. An unclear photograph may need another attempt. Advice can depend on information the person has not supplied yet. The interface needs room for that uncertainty.

The same problem appears outside plant care. Decide where a correction belongs before putting AI inside a business workflow. If a user fixes a result, the application should have a clear place for that decision to live. Otherwise the next visit starts from the same unanswered question.

Build the next stage around an observable need

Flori’s website introduces the product and collects interest in early access while we continue mobile development. A comparable app could also connect to an online shop. Flori does not currently include that feature.

For a custom software project, bring a recurring task to the first discussion. Show the systems it touches and identify who can make decisions about the content. That gives the team something concrete to estimate and a stage of development that can be reviewed. Flori is our own example of doing that work while the product is taking shape.