Journal

AI-generated note (Claude).

So I went down the rabbit hole. Turns out several companies built their entire top-of-funnel on this, and it's actually one of the cleanest PLG mechanics I've seen.

The core insight: a pull request is not an ad. Developers review it on its merits. By the time they realize it came from a company, they already understand the value. That's a crazy good conversion funnel.

The canonical cases

Snyk is the gold standard. When you install Snyk on a repo, it opens fix PRs branded [Snyk]. Every collaborator on that repo, who never heard of Snyk, sees a legitimate vulnerability fix show up. They click it, land on Snyk's site, a big chunk signs up. It spreads within teams automatically. This loop compounded to $343M ARR. OpenView, Lenny's Newsletter, and a bunch of PLG researchers cite this as one of the best growth loops ever built into a dev tool.

Dependabot did something wild early on. Grey Baker would manually search GitHub for PRs with "update" in the title, find devs doing dependency bumps by hand, and comment asking if they wanted to try Dependabot. 50% conversion rate on cold comments. $14k MRR bootstrapped, acquired by GitHub in 2019. The product then did the rest: every repo that onboarded it showered collaborators with [Dependabot] Bump lodash... PRs. One million merged PRs by 2020.

Renovate Bot (acquired by WhiteSource, now Mend) was the open source competitor to Dependabot. WhiteSource made the hosted service free after acquiring it and used it as top-of-funnel for their enterprise security product. Every PR signed by renovate[bot] is a brand impression at exactly the right moment. 1M+ PRs created, 4,000+ GitHub app installs at acquisition. Classic free tool, enterprise upsell.

Imgbot compresses images via PR. You install it once, it sends PRs whenever it finds unoptimized images. There is no dashboard. The PR is the product. Every collaborator sees it. Viral by design.

DeepSource went one step further: they reportedly opened unsolicited config PRs to popular open source repos to get on maintainers' radar. If a 10k-star repo adopts DeepSource, every future contributor sees .deepsource.toml in the repo and the bot commenting on their PRs. Influencer marketing, but in the form of a config file.

Semmle / LGTM ran analysis directly on PRs for 100,000+ open source projects. Every contributor to every monitored repo saw LGTM's inline checks. GitHub eventually just bought them and turned it into GitHub Advanced Security.

Pixeebot sends a security hardening PR to your default branch every week. Weekly brand contact, zero dashboard required. Emerging company, same mechanic.

Why it works

A few things stack up nicely here:

1. GitHub is literally where your ICP lives. No media buy needed.
2. A useful PR isn't filtered out. It gets reviewed on merit.
3. The bot's name is on every PR, forever, in the git history.
4. Lateral spread is automatic: one install, all collaborators see it.
5. Conversion path is short: PR author -> click bot name -> product page -> signup.

When it blows up in your face

Hacktoberfest 2020 is the cautionary tale. DigitalOcean's marketing campaign (make 4 PRs, get a t-shirt) got gamed. A YouTuber with 672k subscribers showed people how to open trivial PRs to any repo. Maintainers got flooded with spam. Drew DeVault called it "a DDoS attack on the open source maintainer community." The Register covered it. DigitalOcean had to retroactively require maintainer opt-in.

The lesson is simple: useful and opted-in = growth loop. Low-quality and uninvited = backlash that spreads faster than the product did. Developer communities are vocal and have long memories.

What this means for building

If you're building a developer tool, the question worth asking is: can your product deliver value through a pull request? Not just integrate with GitHub, but make the PR itself the product touchpoint. If yes, you get co-worker word of mouth at scale without a sales team.

The companies that did this right picked a job developers hate doing (fixing vulns, bumping deps, compressing images) and automated it into their repo. The PR is the value. The brand is just the author field.

Ideas: things you could build

The pattern is clear enough to template. Pick something useful, deliver it via PR, put your name on it. Here are concrete ideas that haven't been fully exploited yet:

README doctor -- a bot that opens a PR improving a repo's README. Better structure, clearer description, badges, usage examples. Maintainers almost always merge a good README improvement. Every merged PR is your brand on a public repo forever. Upsell: a dashboard showing README quality scores across your org's repos.

License bot -- many repos have no license or the wrong one for their use case. A bot that opens a PR adding or correcting the license file. Super simple, always mergeable, instantly useful. Every OSS maintainer has this problem. Could upsell to a compliance tool for companies that need to audit their dependencies' licenses.

Accessibility linter PRs -- scan HTML/JSX for basic a11y issues (missing alt attributes, unlabeled inputs, bad contrast) and open a PR with fixes. Front-end devs care about this but rarely prioritize it. The PR makes it zero-effort to fix. Could layer a full a11y audit SaaS on top.

Broken link fixer -- crawl the markdown files in a repo (README, docs, CHANGELOG) and open a PR replacing or flagging broken external links. Maintainers hate broken links in their docs but don't notice them. Pure utility, very easy to merge.

i18n stub generator -- detect that a repo has a UI but no i18n setup, or has English-only locale files, and open a PR with the scaffold for adding translations. Upsell: a translation management SaaS. The PR is the top of a localization funnel.

Docker/CI config modernizer -- scan for outdated Dockerfile base images, deprecated GitHub Actions syntax, or slow CI configs, and open a PR with modernized versions. DevOps tooling is a mature market but the PR-as-distribution angle hasn't been fully played here.

Changelog generator -- repos without a CHANGELOG.md get a PR that generates one from the git history. Bonus: open weekly PRs keeping it updated. Every collaborator sees the bot name on every changelog update. Upsell: release notes SaaS.

Open graph / meta tag fixer for static sites -- scan repos that are clearly websites (have index.html, etc.) for missing or wrong og:title, og:description, og:image. Open a PR fixing them. Every person running a personal site or docs site has this problem and ignores it. Could upsell to a social preview / SEO monitoring tool.

Scheduling link injector (cal.com-style) -- cal.com is open source and heavily GitHub-native. The angle no one has fully played: a bot that opens a PR adding a booking/contact link to a repo's README or CONTRIBUTING.md. "Want to schedule a call with this maintainer? Book here." Maintainers of popular repos get inbound constantly. A scheduling tool that distributes itself by adding its own embed to READMEs via PR is self-propagating. Every star on that repo is a potential user who sees your brand.

Support platform for repo owners -- most OSS maintainers handle support through GitHub Issues, which is a mess. A bot that opens a PR adding a proper SUPPORT.md, issue templates, and a link to a hosted support widget. Think: open a PR that adds a "Get help" button to the README pointing to your platform. Maintainers who merge it are now your users. Their users become your users. The PR is the signup flow.

Documentation generator -- repos with undocumented public APIs, functions, or components get a PR with auto-generated docs. Could be a docs site scaffold (Docusaurus config, VitePress setup), or just inline JSDoc/docstrings added to the code. Documentation is one of those things every maintainer wants and almost none prioritize. A bot that just does it and opens the PR is immediately valuable. Upsell: hosted docs with search, versioning, analytics.

CONTRIBUTING.md scaffolder -- most repos have no CONTRIBUTING.md. New contributors don't know how to submit PRs, what the code style is, how to run tests. A bot that generates a sensible CONTRIBUTING.md from the repo's existing setup (detects npm/cargo/go, reads the CI config, infers the test command) and opens a PR. Maintainers almost always merge this. Every future contributor to that repo reads your generated file.

Security policy adder -- SECURITY.md is a GitHub-native file that tells people how to report vulnerabilities privately. Most repos don't have one. A bot that opens a PR adding it (with a link to your vulnerability disclosure platform as the reporting channel) is useful, fast to merge, and routes all future security reports through your product.

The common thread: find something maintainers know they should do but never get around to, automate the fix into a PR, and let the git history do the marketing.

AI-generated note (Claude).

Le truc contre-intuitif d'abord: les créateurs qui gagnent le plus ne vendent pas des reviews. Ils vendent l'accès à une audience de devs qui leur fait confiance. La review, c'est le véhicule de crédibilité. Le business model, c'est la sponsorisation.

Ce que font les gros créateurs, concrètement

Fireship (4M subs) gagne ~$679K/an: AdSense + sponsos intégrés en mid-roll (60-90 sec dans ses vidéos) + fireship.io PRO à $495/an. Il ne fait jamais de vidéos dédiées "j'ai testé X pour vous", c'est toujours une intégration dans un vrai contenu. C'est pour ça que ça marche.

Theo (t3.gg) (450K subs) gagne $13K-$41K/mois juste en AdSense, plus des vidéos sponsorisées à $20K+ pièce. Ses sponsors: Vercel, Clerk, Upstash, Axiom. Sa règle publique: "je n'accepte que des outils que j'utiliserais de toute façon et que je continuerais à utiliser après." C'est pas du marketing, c'est sa réputation. Et c'est exactement ce qui fait que ses sponsors paient autant.

NetworkChuck (3.8M subs) ~$800K/an juste en AdSense, plus ses propres produits (NetworkChuck Academy, son café). Il fait exactement le format "je teste ce truc en live", souvent sur des outils self-hosted.

Les tarifs réels des sponsos YouTube

La niche dev tech commande un CPM de $30-60 (vs $10-18 en moyenne sur YouTube). Une vidéo tech avec 100K vues = $1,500-$2,500 en AdSense seul. Ajout des sponsos par-dessus.

Qui sponsorise? Auth/infra (Clerk, WorkOS, Auth0), databases (Supabase, Neon, PlanetScale), hosting (Vercel, Railway, Render), observabilité (Axiom, Sentry, Datadog), VPNs (NordVPN sponsorise 3,000+ YouTubers). Les boîtes d'infra dev payent cher parce qu'une chaîne de 50K devs US seniors vaut plus qu'une chaîne lifestyle de 5M abonnés pour leur conversion.

Newsletters: les chiffres qui font mal

TLDR Tech: 1.6M subs, 46% open rate. Trois slots de sponsorisation par numéro: $15K (primaire), $10K (secondaire), $5K (tertiaire). Run rate ~$7M/an. Un fondateur, petite équipe.

Console.dev: 30K subs mais 77% ont 5+ ans d'expérience. Modèle intéressant: les reviews éditoriales sont totalement séparées des sponsos. Les sponsors achètent une place sous le contenu, jamais dedans. 68% des lecteurs signent pour les outils couverts éditorialement.

SaaSHub: $6.4M de revenue en 2024. 1 employé. C'est un directory de listings avec featured placement à $99/mois. Un des business les plus lean du secteur.

Comment structurer son offre quand on commence

Le piège classique: essayer de vendre des reviews dès le départ sans audience. Ça ne marche pas. Les boîtes ne payent pas pour un avis, elles payent pour une distribution. Sans audience, t'as rien à vendre.

Le bon ordre:

1. Choisir un format précis et s'y tenir. "Je build quelque chose avec X en live et je montre ce qui frictionne vraiment" est bien plus fort que "je review X". Le format "code with me" a un taux de rétention élevé et les sponsors adorent parce que le créateur touche les vrais pain points en temps réel.
2. Faire des reviews honnêtes et non sollicitées pendant 6-12 mois. C'est l'investissement. Theo et Fireship ont leur réputation parce qu'ils ont dit des trucs négatifs publiquement avant de prendre des sponsos. Sans cette base, chaque sponsorisation détruira la confiance au lieu de la monétiser.
3. Publier une page "sponsor me" dès que tu dépasses 10K subs/abonnés. Beaucoup de deals arrivent en inbound si t'as une page claire avec ta niche, tes stats, et tes tarifs.
4. N'accepter que des outils que tu utilises vraiment. Pas pour des raisons morales, pour des raisons business: ton audience le sent immédiatement si tu bullshites, et la confiance est ton seul actif réel.
5. Séparer clairement editorial et sponsorisé. Modèle Console.dev: les reviews sont éditoriales, les sponsors paient pour être à côté, jamais dedans. Ou modèle Theo: disclosure en 30 secondes + overlay screen + mention dans la description.

Le format qui fonctionne le mieux pour démarrer

Le "je self-host X en live" est le format le plus facile à démarrer et le mieux converti. NetworkChuck le fait sur des outils homelab, Dreams of Code sur des alternatives OSS. Le principe: tu choisis un outil OSS (Coolify, Appwrite, n8n, Supabase self-hosted), tu le déploies de zéro dans la vidéo, tu montres vraiment ce qui coince. L'authenticité est structurelle: impossible de tricher sur les erreurs en live.

Pour les reviews de SaaS, le format "je remplace mon outil actuel par X pendant une semaine" est plus fort qu'un review classique. Tu pars d'un cas d'usage réel, tu montres la migration, les limitations, et la conclusion honnête. Les viewers font confiance parce que le coût personnel est réel.

Et si on veut vendre des reviews payantes directement?

Deux modèles qui existent vraiment:

Le productized audit OSS. Des consultants solo packagent un "audit d'adoption OSS" en service fixe: tu veux savoir si tu devrais migrer vers X, je te donne un rapport en une semaine pour $1,500-$5,000. C'est du consulting déguisé en produit, mais ça marche. Le pitch: "je te fais économiser 3 semaines d'évaluation interne." Cible: CTOs et engineering managers qui évaluent des outils pour leurs équipes.

Le "featured review" éditorial. Modèle SaaSHub, Uneed, etc. Tu construis un directory ou une newsletter avec une vraie audience, et tu charges pour la couverture éditoriale ou le featured placement. SaaSHub charge $99/mois pour le featured. C'est de la distribution, pas de l'opinion.

Ce qu'il ne faut pas faire: charger pour des reviews individuelles sans audience préexistante. Les boîtes font la différence entre payer pour une opinion et payer pour une distribution. Sans audience, la première ne vaut rien.

La vraie opportunité sous-exploitée

Personne n'a vraiment construit le "Consumer Reports pour les devs": reviews OSS et SaaS totalement indépendantes, pas de sponsos jamais, financées par les lecteurs via abonnement. Console.dev s'en approche mais reste petit. L'angle: transparence totale sur la méthodologie, refus systématique de tout argent des vendors, financement 100% par les readers. C'est plus dur à monetiser au début mais c'est la seule position que personne ne peut acheter. Et dans un espace saturé de contenu sponsorisé, c'est un avantage compétitif réel.