Most streak mechanics are built on loss. Miss a day and the counter resets. Stop for a month and you're back to nothing.

That works on a language app where the streak is the product. It's a bad idea when the person on the other end is a professional with a schedule, a pipeline, and other clients.

So we built the opposite. Progress is never lost. It only pauses.

Retention is the whole game

Signing an ambassador is cheap. It's mostly a sourcing problem, and you can solve it in a few weeks.

Keeping one producing good content for six months is the actual work, and it's where nearly all the value builds up. A creator on their fourth video understands the product well enough to explain the parts the docs don't cover. That's the content that ranks, and you cannot get it from someone on their first.

Which means the design question isn't "how do we get more creators." It's "what would make a good one drift away," and then removing those things one at a time.

Four states, not two

The obvious design is a switch: active or removed. It's also the design that loses people, because the moment before removal is silent and the moment after is final.

We used four states, with time between each one.

Active. Everything normal, bonuses on track.

Cooling off. A gap has opened. Nothing changes except that a person messages them in their channel to ask how it's going. No penalty. Most people come back at this step, and a lot of them come back because someone noticed.

Frozen. A longer gap. New milestone bonuses pause until they ship something. Everything already earned stays exactly as it is. This is a pause button, not a reset.

Inactive. Off the active roster, done properly with a real offboarding note rather than silence. Progress and earned bonuses are kept. If they want to come back, they get re-onboarded and pick up where they left off.

The rules that matter

  • You never lose what you've earned. No exceptions, at any state.
  • A human check-in happens before anything mechanical does.
  • Frozen pauses new bonuses; it doesn't remove old ones.
  • Leaving the roster is a formal note, not a silent drop.
  • Re-entry is always open, at the progress you had.

Why "never lose" is the load-bearing rule

It looks soft. It's the most practical rule in the program.

A creator deciding whether to make your video next month is doing quiet arithmetic about whether you're worth the slot. If a two-month gap could wipe out a year of accumulated progress, the honest answer is that you're a risk. Risky partners get scheduled last.

Take the loss off the table and the arithmetic changes. Coming back is cheap, so people come back. I'd rather have a creator return after four months than protect a rule that guaranteed they wouldn't.

There's a second effect that took me longer to notice. When nothing can be taken away, the check-in at the cooling-off step stops being a warning and becomes an actual conversation. People tell you they're busy, or that the last brief was painful, or that they're waiting on a feature. You find out why they went quiet, which is information you can use.

Don't demote people by surprise

The same principle applies to tiers.

We didn't cut anyone's rate automatically when their numbers dipped. Tiers got reviewed when a creator asked, on a fixed cycle. If a drop looked sustained, it came up in a conversation.

A rate cut that arrives as a surprise ends the relationship, even when the number justified it. The creator doesn't experience it as a metric. They experience it as being told they're worth less by someone who didn't bother to ask first.

Reviewing on request also flips who's doing the chasing. Creators who've grown come to you, which means the conversation starts on good news and the rate goes up on evidence rather than argument.

What I got wrong

I should have automated the review earlier.

Tight criteria mean every bonus needs a judgment call. I did each one by hand. That's fine at ten ambassadors and a bottleneck the moment it grows. I should have built a review template fed by our own tracking data from week one, instead of adding it after it started to hurt.

The lesson generalises. Any rule you enforce by reading things yourself is a rule that stops working at about the point the program starts succeeding. Write the rule so it can be checked, then check it the slow way until the volume forces your hand — but know in advance where that line is.

None of this works if you can't see what any of it returned. The tracking the whole programme ran on was a tool I had to build myself, in a week, without being able to write it: shipping TubeMonitor.