Why I Built Random Lunch — A Project to End Decision Fatigue

The Question That Repeats Every Day

"Where should we eat for lunch?"

Every office worker faces this question daily. You ask your colleagues. They say "anywhere is fine." You ask again. "I don't care, you pick." Nobody decides, everyone shuffles around, and you end up at the same place you went last Tuesday.

I wanted to fix this with an app. That was the beginning of Random Lunch.

The Idea Was Simple

The concept was clear from the start:

"Show nearby restaurants and randomly pick one."

No recommendation algorithm. No review system. Just random. The reason people can't decide is too many choices — so let the app decide for them.

The one exception: if the result is somewhere you really don't want to go, you should be able to skip it. So I added an exclude feature. Tap exclude, it disappears from the pool, and another one gets picked.

Choosing a Map API

To build the nearby restaurant search, I needed a map API. The two main options were Kakao Maps API and Naver Maps API.

Both had solid Korean POI (Point of Interest) data. But Kakao's place search API had cleaner documentation and was more intuitive to work with. The big plus: tapping a result inside the app could open the full Kakao Maps page for that restaurant — no extra setup needed.

I went with Kakao Maps API. The in-app to Kakao Maps handoff became one of the features users actually appreciated later.

The First Time I Used It

When the MVP was done, I tested it at lunch with a colleague. We hit the button. A list of nearby restaurants appeared. We tapped to randomize. One was selected.

"Eh, not that one." Excluded. Tried again.

Third pick — a place neither of us had tried. We went. It was actually good.

That experience gave me the confidence to push it to the App Store.