Reward loops fire at task 3—mastery needs 11 reps

There's a moment in every product build when the client says "it feels like it's working now" — and it's almost never the moment it actually works. The gap between those two moments is one of the most useful things a developer can understand, because it shapes how you scope, demo, and price your work. So here's the question worth sitting with: if reward loops fire around the third repetition of a task, why does genuine mastery tend to need something closer to eleven?

The warm glow at rep three

Behavioural research has a fairly consistent answer to why early progress feels so good. Daniel Kahneman and Amos Tversky's work on loss aversion showed that we feel losses roughly twice as intensely as equivalent gains, and that our predictions about future experience are systematically skewed by whatever we're feeling right now. Early in a new task, the novelty itself is a small reward — you're learning, errors are cheap, and there's no accumulated expectation to fall short of.

Add variable-ratio reinforcement to the mix and you get something stronger. B.F. Skinner's work on intermittent reward schedules showed that unpredictable payoffs produce the most persistent behaviour — far more persistent than fixed, predictable ones. A new interface that sometimes delights and sometimes frustrates hooks attention in a way a reliable one doesn't. That's worth knowing whether you're designing a dashboard or a checkout flow.

The practical consequence: the third time someone uses your app, or the third sprint of a project, often produces a genuine emotional high. It feels like arrival. It isn't.

Why eleven, and why that number is squishy

The "eleven reps" figure is a heuristic, not a law — it comes from the rough territory where skill-acquisition research places the shift from effortful, consciously-monitored performance to something more automatic. Anders Ericsson's deliberate practice work, and the broader expertise literature, generally puts the meaningful consolidation of a complex skill well beyond the first handful of attempts. Some tasks need fewer; anything with genuine complexity tends to need more.

What matters more than the exact number is the shape of the curve. Early reps produce large, visible gains. Later reps produce smaller gains that are harder to see but far more durable. The reward loop fires where the gains are largest and least meaningful; mastery accumulates where the gains are smallest and most meaningful.

For anyone building websites for businesses, this is a scoping problem disguised as a psychology problem. If you demo at rep three, you're showing the peak of the visible curve. If you hand over at rep three, you're handing over something that hasn't consolidated.

Where this bites in a real build

Consider a mid-sized Australian professional services firm — say, a financial planning practice with about forty staff — commissioning a new site with a client portal. The first two weeks after launch are electric. Staff log in, poke around, find things, tell each other it's so much better than the old system. The reward loop is firing hard.

By week six, the complaints arrive. Not about the design, which everyone still likes, but about the workflows: the thing that takes four clicks when it should take two, the notification that arrives a day late, the report that needs a manual export. None of these were visible at rep three because nobody had done the task enough times for the friction to accumulate into annoyance.

This is the predictable shape of the thing, and it's worth building into the contract rather than discovering it in month two. A structured review at the six-to-eight-week mark — after real usage has pushed people past the glow — catches more genuine problems than any amount of pre-launch testing. Budget for it. Tell the client it's coming. Frame it as the point where the site stops being new and starts being used.

Decision-making under uncertainty, on both sides of the table

There's a second layer here that's less about the client and more about you.

Developers make a long sequence of decisions under uncertainty during a build: which framework, which CMS, how much to customise, when to stop refactoring. Research on risk-taking suggests that people become more conservative after a run of gains and more reckless after losses — the "house money" effect and its mirror image. Early project success can make a team complacent about later architectural decisions; early setbacks can make them over-correct.

Knowing that the rep-three high is chemically real but analytically unreliable is a useful brake. The question to ask at the peak isn't "is this working?" but "what would have to be true for this to still be working in three months?" That's a different question, and it's the one that survives contact with rep eleven.

There's also a competitive dimension. Businesses watch competitors and feel the pull to match features fast — a new booking flow here, a chatbot there. The competitive-play literature on risk-taking suggests that framing matters enormously: when a decision is framed as avoiding a loss, people take bigger risks than when it's framed as pursuing a gain. A client who feels behind a competitor will approve scope they'd otherwise question. Naming that dynamic out loud, gently, is part of the job.

Designing for the eleventh rep, not the third

If you accept the shape of the curve, a few things follow for how you build and hand over.

Instrument the boring middle. Analytics that only track launch-week traffic tell you nothing about consolidation. Track task completion rates, time-on-task, and repeat usage at weeks four, eight, and twelve. The friction shows up there first.

Build for the second-order task. The first time someone books an appointment, they'll forgive a clunky calendar. The tenth time, they won't. Design the flows people repeat, not just the ones they see once.

Make the review a feature, not a failure. A scheduled post-launch review positions the six-week dip as expected rather than as evidence the build went wrong. It also gives you a legitimate reason to be in the room when the real feedback surfaces.

Resist the demo-at-peak temptation. Show progress, by all means, but be honest about which part of the curve you're on. Clients remember being told "this is the easy part" far more fondly than they remember being surprised by the hard part.

The forward-looking version of all this is fairly simple. The websites that earn their keep over years aren't the ones that felt best in week one — they're the ones built by people who expected the glow to fade and planned for what came after. Rep eleven is where the work actually lives. Build for it.