A pre-launch design note on the BTR whistle — how we're engineering it, why it caps at 90 seconds per call, and what we throw out to keep the signal clean.
The whistle button started as a UI flourish. It became BTR's defining interaction — a real-time consensus mechanism that turns the gut-reaction of a stadium into a structured, time-stamped signal.
We don't have live lobbies yet. This piece is about how we're engineering the whistle now, ahead of the South African launch, and the rules that hold whether it's ten fans in a pool or fifty thousand.
Press latency under half a second. Haptic, audio and visual feedback, all within that window. If a fan can't feel the press land, they can't trust the signal.
Every whistle is timestamped to the broadcast clock and gated to a 90-second window around the call. Past 90 seconds, the press still registers — but it doesn't count toward consensus on that specific moment. That gap between "what fans thought in real time" and "what the highlight reel made them think" is the difference we're trying to preserve.
Suspected botting. Repeated whistles from the same account inside the same window. Off-window presses. The cleaner the signal, the more useful it is. The plan is to publish the methodology alongside every consensus stat — including the absolute counts, not just the percentage.
Anyone can shout. What's different about whistle data — by design — is that it's bounded. A fan has to be in the pool. They have to be present at the moment of the call. They can only vote once. We know the exact minute. The structure is the product.
We're not promising fans will get it right. We're promising the question is being asked of the right room, in the right moment, with the count made plain.