The crowd on screen is generating the broadcast

Partway through a drift battle on the Ultimate Drift broadcast, a graphic appears: the crowd thinks this one wins — one driver at near-unanimity, the other with almost nothing. That number is not a producer's guess or a stock graphic. It is the live aggregate of what people watching are picking, right then, inside the app.

That is the whole design, and it runs in both directions. The real event settles the game. The game's aggregate goes back on air as content.

The refusal that started it

When we designed the fantasy layer inside Ultimate Drift, the official app of the Brazilian Drift Championship, the decision that shaped everything was a refusal: we would not simulate the event.

There is an easier version of that feature. It has its own engine, its own probabilities, its own model of how a driver performs. It is simpler to build, simpler to test, and it works whether or not a championship is happening.

That last property is exactly what kills it.

A simulated fantasy game is something you play alone on a Tuesday. Which means it competes for attention with the very event it was supposed to support. You end up with two products pulling in opposite directions: a broadcast that wants you watching, and a game that doesn't need you to.

Settled by the real event, the game can only be played while the event runs. It doesn't compete with the broadcast — it requires it.

The loop closes when the guess goes back on air

Most products that sit next to a live event stop there: the event feeds the app. The interesting part begins when you send the app's aggregate back to the event.

On the Ultimate Drift broadcast that takes several forms — who the crowd thinks wins the battle about to run, which drivers were picked into the most fantasy teams, who was named captain most often. All of it generated by people watching, rendered into the production as content.

Three things change at once:

The spectator becomes a data source. Someone who picks a side is no longer an audience member. They produced a number that is now on screen for everyone else, including the drivers.

The production gets content it didn't have to make. A graphic that is genuinely about this run, this crowd, in this moment — impossible to prepare in advance and impossible to fake convincingly.

Conviction becomes drama. A split near unanimity is far more interesting than a 50/50. If the crowd is overwhelmingly sure and the underdog wins, the broadcast just got a story that nobody wrote. The overlay manufactures narrative stakes out of the audience's own certainty.

What it does to attention

A spectator watching a bracket they have no stake in is consuming content. A spectator who has made a call is waiting for a verdict.

Live sport has long stretches where nothing decisive happens — the setup, the inspection, the wait between runs. Those stretches are where audiences leave. Giving someone a position to defend turns dead air into suspense, not because the app entertains during the gap, but because the gap now has consequences for them.

And once their side is on screen at near-unanimity, the stake is public. That is a different order of investment than a private guess.

What it does to the engineering

This is the part that gets underestimated, and the reason it is a harder build than the simulated version.

Once the real event settles the game and the game feeds the broadcast, you have coupled a consumer feature to a live production in both directions. That changes what reliability means:

• A delayed result is not a data-quality issue. It is a user whose call never resolved — and, on the other side, a graphic that cannot go to air. Latency is measured in trust and in dead air, not in dashboards.
• The aggregate has to be right before the run starts, and frozen at the right instant. Voting that stays open a beat too long means people picking after they have seen the outcome, which poisons the number that then goes on television.
• Failure must be invisible, never wrong. The only acceptable degradation on live broadcast is showing nothing. A graphic that hangs, or shows a stale split, is worse than no graphic — so the overlay's error path resolves to an idle state rather than an error state. It disappears; it never lies.
• There is no maintenance window. The system's busiest moment and the moment it cannot be touched are the same moment.

None of this exists in the simulated version. You accept all of it the moment you decide the real world is the source of truth and the audience is part of the show. That is the trade, and it should be made deliberately rather than discovered on air.

The rule we kept returning to: during the event, nothing is code

You cannot ship an app release in the middle of a championship round. The event does not pause while a store reviews your build, and the audience you care about is the one holding the phone right now.

So we drew a line early: anything we might plausibly want to adjust while an event is running cannot live in a release. It has to be data the system reads at the moment it needs it.

That is not a clever trick, it is a constraint imposed by the physics of a live event — cheap to honour at design time, brutally expensive to retrofit. The question to ask of every rule in a live product is simple: if we wanted to change this at 3pm on a Saturday, could we?

Designing for the person who didn't show up

The easy mistake in any participation feature is to design only for the engaged user — the one who opens the app beforehand and sets everything up.

Most people don't. They arrive late, mid-broadcast, having prepared nothing.

If the product treats that person as having forfeited, it loses them for the entire event — and the event is exactly when they were most likely to become engaged. So "didn't prepare" has to be a designed path, not a failure state: someone arriving cold still needs a position to care about, from the first run they watch.

Deciding that early changes the data model. Retrofitting it later means rewriting the part that decides who is in the game.

Where this applies outside motorsport

Any product that sits next to a real event faces the same fork: simulate it, or be settled by it — and then the second question, whether anything flows back.

Live commerce, conference apps, election nights, auctions. The simulated version ships faster and quietly competes with the thing it was meant to support. The version settled by the event is harder, couples you to an operation you don't fully control, and is the only one that makes the live moment matter more. Closing the loop — putting the audience's own signal back into the production — is what turns a companion app into part of the show.

That choice is a product decision, not a technical one, but it determines your entire reliability architecture. Which is why it should be made by the people who will have to live with both halves — the work we do.

Key takeaways

• A fantasy layer can either simulate the event or be settled by it. Simulating is easier and quietly competes with the event for the same attention.
• The loop closes when the game's aggregate goes back on air: the audience stops being spectators and becomes a visible data source for the production.
• Crowd conviction is itself drama. A near-unanimous split makes an upset into a story nobody had to write.
• Coupling in both directions raises the reliability bar: the aggregate must be correct before the run, frozen at the right instant, and must fail by disappearing rather than by showing something wrong.
• In a live product, anything you might want to tune mid-event cannot live in a release. Ask of every rule: could we change this at 3pm on a Saturday?

FAQ

Why not simulate outcomes — isn't it more reliable?

More reliable and less valuable. A simulation runs without the event, so it competes with the event for attention instead of reinforcing it. The reliability you gain is spent making the broadcast less necessary.

What does "closing the loop" actually mean here?

The event settles the game, and the game's aggregate is rendered back into the broadcast as graphics — who the crowd favours, who was picked most, who was named captain most often. Content that exists only because the audience played.

What breaks when the audience feeds the broadcast?

Your failure modes become visible to everyone watching. The aggregate has to be correct before a run starts, closed at the right moment so nobody votes on a known outcome, and its error path has to resolve to showing nothing rather than showing something stale.

How do you handle results being revised after the fact?

Revision has to be a normal path, not an exception: recomputation that reaches everything downstream, plus an explanation the user accepts. A standing that changes silently feels like a bug even when it is correct.

Does this only apply to sport?

No. Any product adjacent to a live event — commerce, conferences, auctions, election coverage — faces the same choice, with the same consequences for engineering.