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.