Finch

Try the live demo ↗

The AI shopping advisor that has nothing to sell.

Type

Case study

Timeframe

3 days

Toolkit

Figma x Lovable x Gemini

Year

2026

Problem

When you're trying to buy a laptop today, every available tool works for someone other than the buyer. Google serves its advertisers, a retailer's bot serves conversion and average cart size. None of them will ever say "this model is overpriced" or "it's cheaper elsewhere" — structurally, they're judge and party. What's missing is a fourth model: an agent loyal to the buyer by construction — no commission, no inventory to move, and the right to say "don't buy this."

Solution

I designed Finch, a conversational agent that advises on laptop purchases without taking any commission. It pins down the need in two exchanges, recommends at most two machines, finds real listings from the day, and checks the pitfalls of refurbished units on the user's behalf. The core stance: loyalty isn't stated, it's made visible in the interface. Every listing carries badges that separate what's confirmed on the listing from what still needs checking before buying. Trust becomes a component, not a marketing claim.

Finch is a personal project built end-to-end: research, concept, interface design, prompt engineering, and shipping. An AI-native approach — Figma for design, Lovable for prototyping and hosting, and Gemini for the conversational engine and real-time web search.

The goal wasn't to launch a startup, but to test a design hypothesis: an AI agent's loyalty isn't an ethical stance, it's an architecture decision. Here are the three decisions that proved it.

Decision 1: Make hallucinations impossible, not just unlikely

The problem. In early tests, the agent produced product links that looked perfect: clean address, credible-looking ID. They led to error pages. The model was reconstructing URLs from memory. I tightened the anti-hallucination instructions three times; it happened three more times.

The call. I realized a prompt expresses an intention, never a guarantee. The fix wasn't a better instruction, it was an architecture change: never ask the model for a URL again. The agent now provides keywords, and the app's code builds the links to each retailer's internal search.

The principle. The model decides the advice, the system guarantees the links. This boundary between what you delegate to the model and what you lock down in code is, to me, the core of the job when designing a reliable AI product.

Decision 2: A conversational question doesn't break down like a form

The problem. My opening question asked three things at once (new or refurbished, portability, budget), with quick-reply buttons. The system generated absurd buttons like "refurbished, lightweight, under €500" — combinations that only covered an arbitrary fraction of possible cases.

The call. Mathematically, you can't cover a three-dimensional space with four buttons. I restructured it: one dimension per set of quick replies, plus a free-text field kept open for people who already know what they want. The two don't conflict, as long as each does what it's good at — one speeds up simple cases, the other absorbs nuance.

The principle. Quick replies need to be exhaustive on their dimension, otherwise they exclude the user instead of guiding them (Nielsen's heuristics: flexibility of use, error prevention).

vs

Decision 3: Make reliability readable at a glance

The problem. My first badges on listings read "Battery: missing." Testers understood "the laptop has no battery," when it actually meant "this information isn't on the listing." The three-state color code was never explained.

The call. I rewrote every badge from the user's point of view ("Battery: to verify"), reduced it to two readable visual states, added a legend, and made the interface robust: any unexpected value from the model automatically falls back to "to verify" instead of displaying raw data.

The principle. Loyalty shouldn't be claimed, it should be visible in the interface. These badges are the product's signature: they make visible, in the interface, what a retailer's bot will never say.

Method

The project was built with an entirely AI-native workflow: rapid iteration of the conversational engine through prompt engineering, prototyping and shipping on Lovable, and guerrilla usability testing with non-expert users to validate how readable the recommendations were. Every bug encountered (hallucinations, model overload, format overflow) led to a design decision, not just a technical fix.

Limitations, by choice

Finch is a demonstration, not a finished product, and that's a deliberate choice. Its monitoring feature ("I'll watch for new listings for you") is simulated, even though that's exactly what separates a true agent from a chatbot: acting when nobody asked it to. Its knowledge of retailer catalogs is manually encoded and wouldn't scale — on a real team, this would be a maintained database with a named owner.

These limitations aren't oversights: they're the boundaries I chose to set in order to ship a testable product in a few days rather than a project that never ends.