The Map Was Not the Product

When we started Hawkerly, I was very ready to build maps, search, recommendations, location filters, and all the other things a food-discovery app is supposed to have. The map felt like the centre of the product because it was the easiest thing to point at.

After talking to around ten early users, I became less sure. People did care about what was nearby, obviously. But “nearby” did not answer the harder question: what should I eat, and why should I trust this recommendation instead of opening another app?

That changed how I thought about the build. A technically impressive recommendation system is not useful if the result feels random. A perfect map pin is not useful if the stall information is thin. Search is not discovery if users already need to know the dish name.

I had been starting from features

My brain was doing the engineer thing: list the components, choose the stack, design the data model, then assemble a product out of them. The conversations pulled me back toward moments instead. Someone is hungry, in an unfamiliar area, with a budget and maybe three friends who all want different things. What would make the next choice easier?

That is a much better question than “should the map markers cluster?” The clustering can still matter. It just comes later.

I still want Hawkerly to have excellent location-aware discovery. I just no longer confuse the mechanism with the reason the product deserves to exist.