---

name: market-to-devs-sell-to-buyers description: Turn developer love into revenue by enabling champions and choosing a GTM model. Use when developers adopt the free tier but nobody pays, when the user is cold-selling the VP instead of arming the developer, or when picking between open-source, PLG, inbound, and sales-led.

Market to devs, sell to buyers

The developer who adopts your tool is almost never the person who pays for it. Win the developer's heart; then hand them the ammunition to win the budget conversation for you.

Use this when: you have stars, signups, and a beloved free tier, and a revenue line of zero.

The core idea (Czakon)

Market to developers, sell to decision-makers. Developers evaluate and adopt; buyers (CTO/VP/procurement) approve money. Your growth engine is the developer champion who sells internally, so your job is to make them look smart to their boss.

Framework: GTM models that work (Czakon)

Pick the one that fits your product and ICP; don't run all four half-heartedly.

Model	Fits when	The motion
Open source	infra/dev-tool, trust & inspectability matter	OSS core → adoption → paid cloud/enterprise
PLG / self-serve	fast time-to-value, dev = buyer for small teams	free tier → usage → expand → sales-assist on big accounts
Inbound	you can own the problem's content/SEO	educate on the problem → capture → nurture
Sales-led / ABM	high ACV, complex enterprise, few big logos	target named accounts, land via a dev champion

Most dev tools are PLG + a sales-assist overlay for the accounts worth a human.

Framework: enable the champion (Czakon + Frankl)

Give the developer what they need to sell up:

• The Kairos case for their boss (weeks off a release cycle, risk reduced), see value-prop-that-converts.
• A one-pager / ROI snippet they can paste into an internal thread.
• Security/compliance answers the buyer will ask (SOC 2, data handling), the CTO's real fears.
• Proof: attributed results from peers at comparable companies.

Persona → sale map (Frankl): Alpha Dev finds & advocates → VPE/SRE validate feasibility → Empowered CTO approves budget → procurement handles terms (late, enterprise only). A complex sale needs a "what's in it for me" for each. Nail one persona and you get great meetings and no decisions.

Decision tree: when to introduce paid

Has the developer hit real, repeated value (Activation)?
├─ NO  → too early. Gating now kills adoption. Keep delivering value.
└─ YES → is this a small team (dev controls spend)?
         ├─ YES → self-serve upgrade in-product; keep it frictionless.
         └─ NO  → trigger sales-assist: help the champion build the internal case.

Close your first $1M yourself. Don't hand off sales before you've done it. Teaching a rep is far harder than teaching a founder who's felt the objections firsthand (Frankl).

Mistakes that look reasonable

• Expecting developers to have budget: the Alpha Dev loves you and cannot pay you.
• Gating value too early: a paywall before the aha moment converts curiosity into a bounce.
• Cold-selling the VP: bypassing the champion; the buyer trusts their engineer, not your email.
• No champion enablement: the developer wants to buy but has nothing to bring to their boss.
• Four GTM models at 10% each: pick one primary motion and commit.

Your next 30 minutes

• Name your model (OSS / PLG / inbound / sales-led) and the one you'll commit to first.
• Identify your happiest free user → that's a champion. Ask what their boss would need to approve budget.
• Build the champion's one-pager: Kairos case + proof + security answers.
• Define the Activation moment that must happen before you ever mention paid.

---

Built from real dev-tool GTM experience, with frameworks from Adam Frankl (The Developer-Facing Startup) and Jakub Czakon (markepear.dev). Choosing a GTM model is a bet you live with for years. If you want to talk it through, reach out to me on LinkedIn.