| name | founder-led-content |
| description | Build authority by teaching the problem space, not announcing features. Use when the founder finds "marketing" distasteful and does none, publishes only product updates, or wants a sustainable content and GitHub-README strategy that developers actually respect. |
Founder-led content
You don't have to "do marketing." You have to become the person developers trust on the problem. Sell the category, not the product, and let the authority pull people in.
Use this when: content feels slimy so you avoid it, your "blog" is a changelog, or a competitor is quietly becoming the go-to voice while you ship in silence.
The core idea
Developers reward technical depth, honesty, and a real point of view, and punish polished fluff. The move isn't promotion; it's education. Be the trusted expert on the problem, take a stance on where the space is heading, and the product sells itself as the obvious answer.
Before product-market fit, only the founder can do this. It's the #2 hire (DevRel) later, not now.
Framework: authority positioning (Frankl)
- Own the problem, not just the product page. Talks, posts, teardowns, a distinctive thesis.
- Sell the category: teach the problem, describe the need for "a tool like this," share results, without proactively pitching (that trips developer defenses).
- Have an actual point of view on where the industry is going. A trusted expert has opinions; a vendor has features.
The "O'Reilly book" content plan (Frankl): imagine the definitive book on your problem, ~10 chapters, ~10 sections each. That's ~100 genuinely useful pieces mapped out. Publish against the outline consistently. You're writing the book that makes you the authority.
Framework: content & GitHub as distribution (Czakon)
- Teach the problem space (DigitalOcean model): tutorials and deep dives that are useful even if the reader never buys. Curiosity-feeding > promotional.
- README = your real landing page for an OSS/dev tool: what it is (one line) → why it exists → quickstart in <5 min → a copy-pasteable example → badges/social proof. A developer decides from the README, not your website.
- Repo SEO: put the actual search terms in the repo name, description, and topics; developers (and Google) find repos by problem keywords.
- Authenticity over polish: first-person, real, transparent. A rough honest post beats a glossy empty one.
Decision tree: what to write next
Do you have a real, contrarian-but-true opinion about your problem space?
├─ YES → write that. POV posts build authority fastest.
└─ NO → write the tutorial you wish existed when you hit this problem.
(Useful-to-a-stranger is the bar. If it only helps someone who already bought, rewrite it.)
Mistakes that look reasonable
- Changelog-as-content: "we shipped X" is not a story or a draw (Frankl: a feature isn't news; a customer win is).
- "Pleased to announce": nobody cares how you feel about your release.
- Polish over substance: developers smell marketing and leave.
- Neglecting the README: a great product with a lazy README converts nobody.
- Inconsistency: three posts then silence. Cadence you can sustain beats a heroic burst.
Your next 30 minutes
Built from real dev-tool GTM experience, with frameworks from Adam Frankl (The Developer-Facing Startup) and Jakub Czakon (markepear.dev).
When a framework can't make the call, that's what a human is for: The DevTool GTM Company.
