EATS is one of those projects I keep returning to because the problem never really goes away: choosing where to eat is still more annoying than it should be. Search tools give you everything. Group chats go in circles. The places you meant to remember disappear into screenshots, notes, and half-open tabs.
I have rebuilt it three times. The first version was mostly me proving I could connect a frontend to a backend. The second was cleaner on paper, but heavier than the product needed. The current version is the first one that feels like it understands the job: help someone search, inspect, save, and come back later.
Versions
Each version taught me something different. The first taught me the shape of full-stack work. The second taught me that a technically cleaner architecture can still be the wrong product decision. The current one is the first time I felt like I was building the product instead of building around it.
Product
Clerk handles auth. Supabase and Postgres handle data. Yelp is the restaurant source. Tailwind keeps the interface simple. None of that matters much unless the flow stays clear: find a place, decide whether it is worth saving, and come back when the question shows up again.
Why it matters
This project matters to me because it tracks how my judgment changed. I started with "can I build this?" Now I care more about "what actually makes this useful?" The live version is still not final, but it is the first one where the product matters more than proving the stack.
problem
Deciding where to eat still takes more work than it should. EATS is me trying to make that loop feel less like tab management and more like making an actual decision.
constraints
- The first two versions taught me plenty, but they also showed me how easy it is to add architecture before the product earns it.
- Yelp can provide listings, but listings are not the product. The hard part is helping someone filter, save, and come back without friction.
- Auth, saved state, and restaurant data all had to stay simple enough that the app still felt like a tool, not a dashboard.
what it taught me
- A rebuild is only worth it if it removes confusion.
- The real loop mattered more than the stack: search, inspect, save, come back.
- The best version showed up when I stopped trying to prove I could architect everything and started shaping the product around how people actually decide.