Fudi Club
Half a million reviews a week, and one name on the bill for all of it
Restaurant discovery in a South American capital ran on inflated ratings, influencer bartering and pay-to-play lists.
Co-founded against that: an app reading 500,000+ reviews a week, so that a question could be a scenario instead of a category. A quiet place for a business lunch with good coffee, asked in those words rather than picked off a filter list. The owned scope was the whole of it: the app people held, on both stores, the services behind it, everything it had to depend on that belonged to somebody else, and the bill all of that arrived on.
The app had one job on the surface and it was to make a hard thing look like an easy one.
Nobody opens a restaurant app to admire a synthesis of everyone else's opinions. They open it because it is nine at night and the decision is already late. So what arrived on the screen was a verdict and its reasons, in the words somebody would actually use to warn a friend, rather than an average with all the disagreement taken out of it. That verdict is the most expensive sentence in the product, and it is the only reason anybody opened the thing twice.
Reading half a million reviews a week means reading them off somebody else's servers.
Rate limits, availability windows and timeouts are not incidents at that volume. They are the operating conditions, and a design that treats them as exceptions is a design that has not met them yet.
What one bad read is allowed to reach
-
The afternoon
Somebody else's servers go slow, or start refusing, or go away for a while. Nothing on this side caused it and nothing on this side can prevent it.
-
The reflex
Run it again. Cheapest line in the world to write, most expensive one in the system to execute, because it buys back every piece of work the run had already finished and paid for.
-
The reckoning
The week gets paid for twice over an afternoon that belonged to somebody else's infrastructure. Do that a few times and the runway is being spent on work that was already done.
So what a failure is allowed to cost stopped being an operations question and became a design one, taken once and applied to everything: the app, the services behind it, and every outside thing either of them leaned on.
Nothing about the conditions could be negotiated down. What could be chosen was the size of the thing a failure took with it: survivable at the smallest unit of work rather than at the largest, so a bad afternoon cost an afternoon. Unbounded cost is not something to watch for. It is something to design out before there is anything to watch.
What that call bought was permission to keep reading.
Half a million reviews a week is a volume a team either sustains for years or abandons in the first month, and what decides which one rarely has anything to do with the models. It is whether a bad night on infrastructure nobody here controls costs an afternoon or costs the quarter.
And almost none of what the product ran on was owned.
The reviews, the maps, the sign-in, the notification that has to land at the right moment: each of them belonged to a company with its own quarter to worry about and no obligation to stay convenient. Depending on other people is not the risk. Depending on them without having already decided what their bad day costs is.
Then the half of the promise that was never about volume at all.
A question that arrives as a scenario has to come back answered as one, and a quiet place for a business lunch with good coffee is not a category anybody had already written down. Get that last step wrong and everything underneath it is a very expensive keyword filter.
6,000+ establishments indexed across the city, and an app on both stores that carried them.
Millions of reviews processed across two-plus years of operation, on a bill that stayed a decision rather than a monthly surprise. The market timing was wrong, and the product was wound down before burn outran what it had proven.