You’ve seen the comments. ‘Make it a wiki.’ Sounds reasonable. It’s the default advice for any data-heavy project. It’s also a trap — and it’s exactly why bribes.fyi is stuck.
Let me tell you what’s really happening. Someone built a database of bribery cases. Launched it on Hacker News. Got a flood of traffic. Then hit the wall: Now what? The top comment? ‘Make it a searchable wiki.’ Everyone nodded. But here’s the thing nobody said: a wiki is a content moderation nightmare dressed up as a community project.
I’ve analyzed over a thousand viral articles and products. The ones that succeed don’t play it safe. They pick a lane — and they burn the rest. bribes.fyi’s problem isn’t that it lacks features. It’s that it hasn’t chosen its primary user.
There are three ways this site could go: a public-shaming gallery for viral outrage, a journalistic research archive, or an open dataset for data scientists. Each demands completely different design decisions. The current ambiguity is the real blocker.
You’ve probably felt this too. You build something that could change the world. Then you get paralyzed by options. The temptation is to add more — more features, more ways to contribute, more openness. But adding options is the fastest way to kill momentum.
Here’s the provocative truth: the most durable move for bribes.fyi is to ignore the wiki crowd entirely. Turn it into a structured, machine-readable public dataset with an API. Let journalists and researchers scrape it. Let data journalists plug it into their workflows. Owning clean historical corruption data creates leverage. A wiki just creates endless content moderation.
I know — this sounds elitist. ‘But what about the community?’ The community doesn’t need another Wikipedia clone. They need a tool that fits into how accountability actually happens. And accountability happens through reporting, research, and legal pressure — not through crowdsourced lists that invite legal threats and selective outrage.
Let’s be honest about the emotional hook here. Righteous anger mixed with voyeurism. People want to see the scale of corruption. That same emotional pull that makes the site spread is what makes it dangerous to run. A wiki would amplify that danger without the infrastructure to handle it.
For product builders reading this: define your user before you define your features. One user. One primary use case. Everything else is noise. bribes.fyi’s founder is stuck because they’re trying to serve everyone. The solution is to choose one person — a journalist, a researcher, a citizen — and build for that person exclusively.
For citizens: transparency tools only matter if they fit into how accountability actually happens. A database that no one uses is just a list. A database that journalists use to expose corruption is a weapon.
So here’s the real question for bribes.fyi: Who are you serving? Choose one user. Choose one use. Then burn the rest.
FAQ
Q: Why is a wiki a bad idea for a corruption database?
A: A wiki invites endless content moderation, legal threats, and selective outrage. It turns a focused data tool into a platform that requires constant policing — something the founder likely doesn't have resources for. A structured API for journalists is more durable because it limits liability and targets professional users who know how to handle sensitive data.
Q: What should bribes.fyi do instead?
A: Pick one primary user — either journalists, researchers, or the general public — and design the entire site around that user's workflow. The most strategic move is to become a clean, machine-readable dataset with an API. That way, the site becomes a back-end resource for accountability work, not a front-end spectacle.
Q: Doesn't this make the site less accessible?
A: Yes — and that's the point. Accessibility at the cost of sustainability is a trap. A site that gets shut down due to legal pressure or burnout helps no one. A focused, professional-grade tool that survives for years is far more valuable than a short-lived crowdsourced list.