grabbit food finder proof-of-concept
A Visual Feed for Food Discovery
grabbit was a concept developed during my time at Israel Tech Challenge. I led UX/UI from concept through execution—defining the product direction, designing the experience, and shaping how the core model would work.
My Role
0 to 1 UX UI
Assumption
Killing the “I Don’t Care, You Pick” Loop
This isn’t just small talk—it’s a daily decision loop that wastes time and leads to mediocre outcomes.
The assumption:
People often don’t know what they’re in the mood for
Others default to indecision to accommodate the group
Existing tools assume you already know what you want because they are built around intent-based search (e.g., “Thai food,” “brunch,” “restaurants near me”)
General searches require guessing the right keywords
Reviews are subjective and often conflicting
Content is buried in long-form blogs or scattered across platforms
Great local spots are often invisible unless you know what to look for
The result: decision fatigue, wasted time, and unsatisfying choices.
Original mock-ups
Key Features
Designing for Indecision
Instead of keyword-based searching, users would browse real, recent food near them and could make faster, more confident “gut” decisions—without needing to know what they want upfront.
We focused on a tight MVP to validate the core behavior: fast, visual decision-making without search.
Real-time, user-generated food photos
The foundation of the experience—what people are actually eating right now. No reviews, no long descriptions—just immediate visual signal. Content is primarily user-generated, supplemented by scraped imagery from sources like social media, Google Maps, Yelp, and restaurant-provided photos—ensuring density and variety even in less active areas.
Recency-driven feed
A lightweight ranking model prioritizing recent, relevant content ensuring users see what’s good right now, not what was popular months ago—while still allowing light filtering when needed.
Location-based discovery
Content is surfaced based on proximity, making discovery hyper-relevant. Users can explore a specific area and seamlessly transition from browsing to action with one-tap directions via native maps.
“GrabbIt” swipe for the undecided
For users who don’t know what they want, a swipe-based flow removes the need to search entirely. Set a few lightweight parameters, then quickly pass or “GrabbIt”—turning indecision into momentum.
Lightweight content classification
Images are organized using metadata and simple categorization (e.g., burgers, sushi, drinks), making content browsable without requiring manual tagging or effort from users.
Claude Code
Before writing any code, I asked Claude what it needed from me to actually build something good. That answer shaped how I approached every project after. I structured my prompts around six elements — and came into each one prepared:
Full product scope
Clearly defined MVP features, including how each functioned and how users would navigate between them—removing ambiguity upfront.Target user
Grounded decisions around tone, density, and interaction patterns.Aesthetic direction
Provided my original mockups as a starting point to avoid generic AI outputs, then iterated heavily to refine the look and feel.Key interactions
Prioritized the moments that mattered most (e.g., swipe decisions, browsing flow), ensuring the prototype focused on behavior—not just screens.Technical constraints
Specified the environment (e.g., React, state handling), which helped produce something closer to a real, working system.A creative north star
Defined the one thing the product needed to feel like—so decisions stayed cohesive, even as we iterated.
For aesthetic direction, I gave Claude my original mockups as a starting point — something concrete to react to rather than start from zero. For the feature list, I mapped out every MVP function and how a user would actually move through each one.
The first result was killer. From there, it was a lot of back and forth — getting the right open-source images to match each restaurant, building out mock data so the app actually felt real. I also caught a few bugs along the way. One example: the map's z-index was sitting higher than the Restaurant Sheet, so the map was staying on top in map view. Having some coding knowledge from a bootcamp I did made a real difference — I could articulate exactly what needed to change, which made the fixes fast and precise.
That's the dynamic. Claude handles the execution. But the quality of what comes out is a direct reflection of the direction you put in.
Future Enhancements
Building Toward Something Bigger
This was an idea I'd been sitting on for a while — and finally building it felt like a long time coming. Turning it into something real was one of the more exciting things I've done creatively. I plan to keep building on it, and maybe even find some funding someday.
A few things I'd want to tackle next:
Profiles & Content
Ownership Simple user profiles with the ability to upload and manage your own content. Authentication would be phone-based (SMS) or social login — no email and password nonsense.A Social Layer
Follow friends and restaurants, save favorites, and make food discovery actually feel collaborative. Half the fun of finding a good spot is sharing it."Swipe Together" for the Undecided Feature
Share a link, swipe at the same time, and when you match — you go. Takes the whole "I don't care, where do you want to go" conversation off the table.
Summary
I approached Claude Code and AI like a collaborator, not a shortcut. By clearly defining the problem, user behavior, and system constraints, I was able to guide it from vague outputs to a functional prototype—iterating together until the experience felt real, not just designed.