7 min read
Webapp & AI2026 — Product Designer

Onz: Letting AI decide what's for dinner

Role
Product designer, end to end
Team
Solo design, Kaizer Studios
Timeline
2025–26, launched 1 Feb
Platform
Responsive webapp, AI

Executive summary

1 minute read
Problem
People burn >10 minutes deciding where to eat. In a 47-person survey, 91.5% said the choice was hard and 57.4% said the real blocker was not knowing what they were craving.
Hypothesis
If a recommendation came from your own taste profile rather than a crowd average, the decision would collapse from ten minutes to under three.
Solution
A taste profile built from your own reviews, with a private layer so honest ratings stay honest. Friends' recommendations first, then a daily AI curated list of restaurants came after.
What changed
Launched 1 Feb 2026 at getonz.com. 80.9% of surveyed users said they'd use it weekly. Eight actually did. Then I recommended we stop, because changing someone's thought process is harder than shipping the feature that assumes you already have.

01 — Context

Onz was a food decision app I designed and developed end to end at Kaizer Studios and launched publicly in February 2026. It started from one stubborn, unglamorous problem: the 10+ minutes a group burns deciding where to eat, and the fact that no existing app was built to end that conversation.

02 — The problem

Every discovery app answers "what is near me" in an area of more than a hundred options, which is not the question people are stuck on. In a 47-person survey, 91.5% said choosing where to eat was difficult and 57.4% named the real blocker: not knowing what they were craving. This is option overload, not option scarcity, and adding filters makes it worse.

Fig 01Before state — the category-and-rating pattern shared by every discovery app. Annotate the step where the user has to already know what they want in order to use it.

03 — Constraints

  • Solo design and builder. Anything needing a trained model was out of scope for the MVP.
  • No complete restaurant data partnership — only what's in the Google Maps API, so the first taste profiles had to be built from user reviews alone.
  • Klang Valley only at launch, which capped how much the recommendations could learn.

04 — What we learned

Forty-seven people, one survey, and a pattern that held. The blocker was never too few options; it was having no way to name a craving. 68.1% asked for mood-based curation before they asked for anything else, which told me the entry point was a feeling, not a cuisine.

Fig 02Research artifact — the survey breakdown, or an affinity map of the 47 responses with the craving-vs-choice split called out.

05 — The move

So the profile came first. Every recommendation has to trace back to a taste profile you built yourself, not a crowd average — so the shortlist re-sorts the moment you rate a single dish.

Fig 03Onboarding core interaction — dietary requirements, favourite cuisines, dining preferences. The whole algorithm and recommendation learns off these three items.

06 — What shipped

  1. AAn AI recommendation engine based on a taste profile assembled from your own dish-level reviews, not a star average.
  2. BA dual review layer: a public one, and a private one only you see, which is what actually trains the profile.
  3. CAn AI-powered daily shortlist short enough to decide from, capped rather than infinite.
Fig 04Shipped UI — three tiles daily shortlist, the public review listing, and the profile.

07 — Tradeoffs

Friends' recommendations weren't a replacement for the algorithm — they were a manual stand-in for the same signal it would eventually provide, shipped first because the AI engine went live right after and needed real taste data to work from. The tradeoff sat in that first window: without a model yet, the profile only got sharper if you kept reviewing, so retention had to carry weight the product had not yet earned.

08 — What changed

80.9%
surveyed users who said they'd use it weekly
8
who actually did, in Klang Valley at launch
68.1%
who wanted mood-based curation first

09 — Why we stopped

Eighty-one percent said weekly. Eight showed up. Market research showed a better-funded competitor closing the window, and the honest read was that the gap was structural, not a marketing problem. I made the case to wind Onz down. The same evidence standard that justified the design justified stopping it, and that judgement became the validate-before-build gate every Kaizer venture now runs through.