TasteBuds

Everyone knows how the conversation goes. Someone suggests a place. Someone else does not eat that. Someone asks what everybody wants, the thread goes quiet, and long after it should have been settled nothing has been decided and one person chooses for the group. The people with dietary restrictions spend the whole exchange feeling like a constraint rather than a guest.

The problem was never that people want different things. It is that there is no efficient way to surface everyone's preferences at once, account for the restrictions, and find the intersection without a long back-and-forth. Group chat is the wrong tool: it is sequential, it favours whoever speaks first, and it has no memory of what anyone said a few messages ago.

TasteBuds was built to turn that negotiation into a structured process. Collect what everyone needs, compute what works, propose it, confirm. The conversation is still there if people want it. It just starts from an answer.

A consumer social app gets one chance. A person who opens TasteBuds for the first time and does not get something useful within the first two minutes will delete it, and there is no onboarding grace period in which to earn a second look. The app had to prove itself in its first real-world use, which meant preference aggregation and restaurant surfacing had to work well from session one, before anyone had spent time building a profile.

That constraint set the priorities. The build concentrated on the core loop and nothing else: create a group, collect preferences, get a recommendation, confirm, go eat. Anything that did not shorten the path from opening the app to sitting at a table was left out.

One person creates a group for a specific outing and invites the others with a link. The point of the link is that a friend who has never heard of the app can answer straight away. Each member fills in a short set of questions: cuisine preferences, dietary restrictions, price range, and any cuisines or restaurants to rule out.

The app aggregates the answers, finds the overlap and surfaces restaurants that work for everyone in the group, ranked by how well they satisfy the collective constraints. A hard restriction eliminates; a preference weighs. The group creator sees the ranked results and proposes one. Others can vote, comment or suggest an alternative from the list. When there is consensus the restaurant is confirmed and everyone has the address and details in the same place.

Profiles persist; groups do not. Preferences and dietary restrictions carry over between outings, so nobody re-enters a restriction they have lived with for years. Groups are disposable, created for an event and left behind, which keeps the app free of the stale lists that clutter every messaging tool.

The obvious design was a vote. Each member ranks a shortlist of restaurants and the group goes with the winner. It is intuitive, it is familiar, and it is what most groups already do badly in a chat.

It fails at precisely the case the app exists for. When one person has a dietary restriction that rules out the winning option, the majority has chosen a restaurant that excludes someone at the table, and the app has formalised the thing that made group dinners unpleasant in the first place. Voting optimises for the most popular choice. The group needs the most inclusive one.

Preference overlap starts from the constraints and finds what satisfies all of them, then ranks within that set by preference. A restaurant everyone can eat at is more useful than the one most people prefer if it leaves someone ordering a side salad. Voting was kept, but only as a way to choose among options that already work for everyone.

A typical outing begins with a tap to create the group and a link dropped into whatever chat the friends already use. Each person opens it, confirms or updates their saved profile, adds anything specific to tonight, and is done. The organiser watches the answers arrive.

The ranking happens automatically as responses come in. The organiser proposes the top option, or a different one from the list, and the group votes or comments. Once confirmed, the details are in everyone's hands and the group can be forgotten. Nobody compiles the preferences by hand, nobody argues over a restriction they did not know about, and nobody has to be the one who finally decides.

TasteBuds launched in New York with the core loop complete. A group creates a session, collects preferences in under two minutes and has a shortlist of restaurants that work for everyone before the conversation has had a chance to stall.

The friction of the group decision is front-loaded into a fast, structured step rather than spread across a thread nobody wants to resolve. Underneath sits a preference engine that treats restrictions as hard constraints and tastes as weights, and a profile that remembers both, which is the foundation every later outing draws on.