market-to-devs-sell-to-buyers

# 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*).
When a framework can't make the call, that's what a human is for: [The DevTool GTM Company](https://thedevtoolgtmcompany.com).