Growth Loops

Growth loops (the next 5,000 without you)

You got your first 50 users by hand: DMs, favors, one good launch. That was the right way to get them, and it was never supposed to scale. A growth loop is what comes next: one user's ordinary use of the product exposes it to the next user, and that user repeats it. Not a one-time referral; a continuous cycle.

Use this when: growth flatlines every time you stop posting, you can trace every user to a founder DM or a launch day, or you're about to add a third channel when the users you already have produce zero new ones.

The core idea

A channel is linear: effort in, users out, stop pushing and it stops. A loop feeds output back into input: usage creates an artifact, a public trace, or an invitation that a new developer finds, and that developer's usage restarts the cycle. Channels deplete; loops compound.

The rule that keeps it non-slimy: every loop must do the user a service, not just you. A branded report the user is proud to send is a loop; a watermark they resent is spam with extra steps. If the loop degrades the experience, it is not a loop, it is a leak in your trust.

The gate: a loop amplifies whatever you feed it. If week-2 retention is broken, a loop compounds churn, not growth. Before this skill: first value in under an hour (time-to-first-value), first 50 real users in hand (first-50-users), and cohorts that come back (know-if-its-working, Frankl's net developer retention). If any of those fail, that failure is your Now move, not this.

The dev-tool loop catalog

Six loops that actually work for developer tools. You need one, running at full strength.

1. Showcase loop. The product's output is shareable and carries your name with it: a CodePen link, an exported report with the logo intact, a "Generated by X" footer on docs. crowd.dev's exported community health reports carried the branding; recipients asked how the report was made, and that question was the signup.
2. Badge loop. A status signal developers want in their README: "build passing" (Travis CI, CircleCI), coverage percent (Codecov). Every visitor to every repo that uses you sees a micro-advertisement, and the badge earns its place by signaling quality, not by begging.
3. Workflow loop. The tool acts inside a shared workflow where non-users see it working. Snyk auto-opens pull requests with vulnerability fixes; every collaborator reviews that PR, discovers the tool, and signs up. A bot comment on a fixed issue, a summary email a dev forwards to the team: same mechanics.
4. Team loop. One developer adopts, and the tool lands in a shared repo, a CI pipeline, or a lockfile every collaborator now touches. Then it walks out the door when a dev changes jobs and installs it on day one. The qualifying question: does the tool become more useful when more people use it together? If yes, build the invite into onboarding, not into a popup.
5. Public-content loop. Usage produces content strangers find: user-created projects and collections browsable in public (StackBlitz, Postman's public workspaces), community answers that stay indexed instead of dying in a ticket, and the tutorials their questions teach you to write (founder-led-content is this loop's fuel).
6. Marketplace loop. Live where developers already shop: a VS Code extension, a Jenkins plugin, a framework's starter gallery, GitHub's own surfaces (trending, "used by", dependents). Every new user of their platform can now discover yours.

Decision tree: pick your one loop

Does normal use already produce something other developers can see
(an output, a badge, a PR, a config in a shared repo)?
├─ YES → showcase, badge, or workflow loop. Instrument what is
│         already happening before you build anything new. This is
│         the cheapest loop you will ever get.
└─ NO  → is the tool more useful when a team uses it together?
         ├─ YES → team loop: put the invite where the value is,
         │        not in a growth popup.
         └─ NO  → do developers search or ask in public when this
                  problem bites?
                  ├─ YES → public-content loop: answer and publish
                  │        where it gets indexed, every time.
                  └─ NO  → your ICP may be too diffuse to loop.
                           Tighten it in `who-is-this-for` first.

Measure the loop, not the traffic

One question, monthly: of your new signups, what share came from an action an existing user took (a badge click, a shared artifact, a fix PR, a committed config, an answered thread)?

• Under 10%: you have channels, not a loop. Fine at 50 users, a problem at 500.
• 30% and rising month over month: the loop is turning. Feed it before you add anything else.
• Track cycle time too: a loop that takes two weeks per turn compounds; one that takes six months is a channel wearing a loop costume.
• Attribution here is directional, not precise (Czakon): the free-text "how did you hear about us?" field is your honest instrument. Tag every answer loop or channel.