AICase study · 2026
Floral Recognition Interface
A design-led AI experiment: upload a bouquet photo and get a cinematic floral breakdown, with numbered markers and specimen details for every flower the model can see. Started at a Cursor build event, refined over dozens of passes into a live public demo.
Context
A self-initiated AI experiment. It started at a Cursor build event in Sydney with about an hour on the clock, and grew over dozens of passes into a live public demo with validation, shared history and its own usage gate.
My role
Everything: the concept, UX and UI direction, interaction design, the AI workflow, the build, deployment and iteration.
Stack
Figma for direction, Cursor for the build. React + Vite on the front, Gemini for recognition, Vercel API routes behind it, Upstash KV for shared history.
Status
Live public demo, desktop-first. Mobile is still to come.
What if you could upload a bouquet photo and get a cinematic, sci-fi floral breakdown in seconds?
The interface
The visual direction is a techy HUD language applied to something as soft and organic as flowers. A photo goes in, the scan runs, and the bouquet comes back as an annotated specimen sheet.
What it does
Floral scan
Upload a bouquet image, the model identifies the visible flowers, and the UI overlays numbered markers with specimen details: species, common context, and a confidence figure.
Invalid input
Non-floral uploads are rejected with a clear floral-only prompt. It keeps the experience constrained to its intended use instead of pretending to analyse whatever it is given.
Shared analyses
Visitors can browse scans from previous users, so the demo feels alive and social rather than a private sandbox that resets for every visitor.
Usage gate
After the free scans are used, an access code is required to continue. It protects the API from abuse and keeps a public AI demo sustainable to run.
Only valid floral scans count toward the shared totals and history.
Four user flows
Each user flow, captured from the working demo. Pick one to watch it run.
1 / 4
floral · scan
Why flowers
I did not start this because I found a market gap. I make floral bouquets, and I wanted a way to present that work in my portfolio that could carry the story and detail of each arrangement. A standard gallery grid flattens all of that.
Around the same time I attended a Cursor build event at Dovetail in Sydney, with roughly an hour to build something AI-integrated. I went in with the bouquet idea, and the rough version that came out of that hour worked. People responded to it and genuinely liked the uniqueness of it, and it stopped being a fun hack and became something I wanted to keep refining.
Direction before AI
I did not want AI-generated visuals deciding the look of the product. Left to drive, the output drifted generic. So I designed the direction in Figma first, a techy HUD language for something as soft and organic as flowers, partly inspired by the portfolio of a Switzerland-based product designer (sutera.ch). Then I iterated in Cursor for dozens of passes until the build matched the intent.
The big takeaway: AI is powerful when you have direction and mediocre when you let it drive. People keep saying design and dev will be replaced by it. My experience was that the tools sped me up precisely because I knew what I was aiming for.
The four flows
1 / 4
floral · scan
Floral scan
Upload a bouquet image, the model identifies the visible flowers, and the UI overlays numbered markers with specimen details: species, common context, and a confidence figure.
What fought back
This project taught me more from its constraints than from its features.
1API limits are real
I had heard about quotas and token limits, but I did not feel them until they interrupted the build. Free tiers forced me to learn practical AI economics: what to run locally, what to call once, and when precision is worth paid usage.
2Markers are not magically aligned
Model output can be semantically right and visually noisy. Anchors and bounding boxes kept missing the flowers, so I moved to a numbered pin system that stays legible even when the geometry is imperfect.
3Deployment is part of the design
I expected a one-click launch and got environment and workflow friction instead. The app was usable locally well before it was reliably public, and that gap shaped what the finished version could realistically be.
Under the hood
Frontend
React + Vite
Model
Gemini (Flash family) for classification, detection and annotation output
Security
API key moved off the client into server environment variables
Backend
Vercel API routes for analysis, usage, access codes and shared history
Persistence
Upstash KV for the shared counters and history
Deployment
Public on Vercel
What this changed
I came out of this with a different way of working. Move fast to a rough prototype, then iterate in tight loops instead of treating each prompt as a final answer. The interface only started to feel right once I brought my own visual judgement to the pixels, the states and the micro-details, and held every pass to a standard of consistency. Quality came from dozens of small decisions, a lot of patience, and honestly a lot of Cursor credits.
The constraints stopped being afterthoughts and became part of the brief: deployment friction, API limits, usage guardrails, and a deliberate desktop-first scope. Mobile is still to come.
Thanks for the feedback, encouragement and honest critique along the way: