Early monetisation for a creator who has not scaled yet

This is an illustrative scenario, not a customer account. Our
platforms are in closed testing and we have no live results to report. What follows is a real
problem, described honestly, with the reasoning we would apply to it.

The situation

A streamer has built a consistent audience of a few thousand concurrent viewers. It is a good
audience — engaged, regular, and specific enough to be genuinely valuable to the right brand. It
is also below the threshold at which most platform monetisation programmes will pay anything at
all.

So they are doing the hardest part of the work — building the audience — in the window where
the economics offer them the least.

Why the usual answers do not fit

Platform revenue share is gated on scale they have not reached, and pays on a
split calculated after the month closes.

Direct brand deals require a manager, a media kit, an invoice and a
follow-up. At the value these deals command, the administrative cost consumes the margin, and
most creators at this stage are doing it alone.

Affiliate links pay on conversion, which transfers the entire performance
risk to the person with the least ability to carry it.

How we would approach it

1. Price the audience rather than the follower count. A specific, engaged
   audience of a few thousand is worth more to the right advertiser than a diffuse one of a hundred
   thousand. The threshold model cannot express that; a stated rate can.
2. Make the offer before the work. The creator sees the brand, the format and
   the rate, and decides. No pitch, no media kit, no negotiation they are poorly placed to win.
3. Keep the format inside their existing workflow. An overlay composited in the
   broadcast software they already run costs them no production time.
4. Pay on verified delivery, independent of what the advertiser paid.

What we would expect to be hard

Verification. Paying on delivery requires knowing delivery happened, without instrumenting the
viewer — which we will not do. That constraint is the interesting engineering problem in this
scenario, and it is the one we are spending our time on.

We will publish measured outcomes when we have them, and we will say plainly that they are
measured.