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.

Mistakes that look reasonable

• Building a loop on leaky retention. Amplifying a product people abandon just abandons faster. The gate is the gate.
• Paid referral incentives for developers. "Give $20, get $20" reads as bribery to the exact audience that punishes it, and it poisons the genuine recommendations you already get. Devs refer because the tool made them look good, so make that effortless instead.
• Forced virality. An unremovable badge or watermark gets stripped, resented, and posted about. Dual value or nothing: the loop must serve the user first, and stay deletable. The ones that remain are worth more.
• Mistaking a launch spike for a loop. A launch is one crank of the handle (launch-it). The test is whether the users it brought produce users. If the graph decays back to baseline, it was a channel.
• Running three loops at 30%. Each half-built loop below critical mass produces nothing. One loop compounding beats three leaking; add the second when the first runs without you.
• Copying B2C mechanics. Waitlists, invite gates, and streaks signal "growth-hacked" to developers. The first rule still holds: don't lie to developers, they find out.

A worked example

Snyk's core loop is the workflow loop run to perfection: the product's normal job is opening pull requests that fix vulnerabilities. Every teammate who reviews one of those PRs sees the tool doing something undeniably useful, in their own repo, with zero pitch. The exposure is the value delivery; nothing was bolted on. Contrast the failure mode: a tool that appends "try X!" to commit messages delivers the exposure without the value, and gets uninstalled. Same surface, opposite outcome. The question to steal is not "where can I put my logo?" but "where does my product already do visible work a stranger would respect?"

Your next 30 minutes

• Take your last 20 signups and sort them: founder action, launch spike, or existing-user action. Count the third pile honestly. That number is your baseline.
• Walk the catalog and circle the ONE loop your product's normal use already half-performs. Don't invent; instrument.
• Find the visible work your product already does that a stranger would respect, and make it carry a tasteful, removable link.
• Confirm "how did you hear about us?" exists as free text (see know-if-its-working), and start tagging answers loop vs channel.
• Check the gate: if week-2 retention is broken, park this skill and open time-to-first-value. Loops wait; churn doesn't.

Built from real dev-tool GTM experience, with frameworks from Adam Frankl (The Developer-Facing Startup) and Jakub Czakon (markepear.dev). The loop catalog is adapted from Jonathan Reimer's Growing Developer Tools: A Handbook, with the loop model from Brian Balfour and Casey Winters (Reforge).