DEV Community: Daria Dovzhikova

We benchmarked an AI agent on 52 broken clusters: kubectl vs a Kubernetes MCP server

Daria Dovzhikova — Tue, 21 Jul 2026 09:52:24 +0000

Disclosure up front: I work on Radar, the open-source Kubernetes UI whose MCP server is one side of this benchmark. The method is published, so you can check the work.

Everyone is plugging AI agents into Kubernetes right now, and the default move is to give the agent a shell and let it run kubectl. It works. The agent gets there. But nobody seemed to have measured what that approach actually costs, so we built a harness and did.

The setup

52 fault-injection scenarios on a live EKS cluster: crashloops, misconfigurations, resource pressure, broken rollouts, and the messier indirect failures where the symptom is far from the cause.
One model on both sides: Claude Sonnet 4.6.
Two conditions. Condition A: the agent gets a shell and raw kubectl. Condition B: the same agent connects through Radar's MCP server.
Same prompts, same success criteria, scored on whether the agent found the actual root cause.

The only variable is how the agent sees the cluster.

The results

Per-trial averages across all 52 scenarios:

Metric (per trial)	kubectl	Radar MCP	Change
Tool calls	45.8	11.1	76% fewer
Input tokens	4.9M	2.3M	53% fewer
Output tokens	3,040	1,039	66% fewer
Agent time	334s	169s	49% faster
Pass rate	77.6%	80.8%	small increase (+3.2pp)
Diagnostic score	0.765	0.862	small increase (+0.097)

The headline is the efficiency column. The accuracy rows are there to show the speedup wasn't bought with correctness: it nudged up rather than degrading.

Why the gap exists: it's the context, not the protocol

The tempting reading is "MCP beats shell access." That's not quite it, and it matters, because plenty of Kubernetes MCP servers are essentially a proxy to kubectl: the same raw output over a newer transport. Wrap kubectl in MCP tools and I'd expect numbers close to the kubectl column.

Watch a kubectl-driven agent work and the cost is obvious. It runs get pods, then describe, then logs, then get events, then describe on the owner, and after every call it re-derives the same structure from text: which replicaset belongs to which deployment, which service fronts which pods, what changed before things went bad. That structure never persists between calls. The agent pays to rebuild it, in tokens and in round trips, over and over.

Radar's MCP server hands the agent that structure as ready context. Two pieces do most of the work:

The resource graph. Ownership chains, service routing, what's connected to what. One tool call returns the neighborhood of a failing resource instead of five calls' worth of raw output to correlate.
The change timeline. What was deployed, scaled, restarted, or rolled back, and when. Most diagnoses are some form of "what changed?", and giving the agent the answer as data beats making it reconstruct the sequence from events and log timestamps.

That's the whole trick: better data in a better format. 45.8 tool calls collapse to 11.1 because most of those calls existed to rebuild context the server can simply provide.

Where the gap was widest

Not on the easy faults. A pod stuck in CrashLoopBackOff with an obvious error in its logs gets diagnosed either way, and kubectl does fine.

The gap opened on indirect, cross-cutting failures: the ones where the failing thing isn't the broken thing, and the trail crosses resource boundaries. Those are exactly the cases where a human relies on knowing the topology and the recent history, and the agent behaves the same way. With the graph and the timeline in context it followed the chain; with raw output it burned calls wandering.

Honest caveats

The accuracy gain is small. +3.2 points of pass rate is a nudge, not a leap. If you want this benchmark to prove agents get dramatically smarter with MCP, it doesn't. It proves they get dramatically cheaper and faster at the same quality.
One model. We ran Claude Sonnet 4.6. The mechanism (ready structure is cheaper to reason over than raw text) shouldn't be model-specific, but we haven't measured others yet. If you run it on GPT, Gemini, or a local model, I'd genuinely like to see the numbers.
52 scenarios. Big enough to see the pattern, small enough to inspect by hand. We'll grow it, and if there's a fault class you think is missing, tell me.

Try it or reproduce it

The full method is in the benchmark write-up this post is adapted from, and the background on how the MCP server builds live cluster context is here: MCP for Kubernetes: live cluster context for AI tools.

Radar is a single Go binary, Apache-2.0, no account, nothing installed in the cluster. It reads your kubeconfig and respects your RBAC:

curl -fsSL https://get.radarhq.io | sh && radar

Repo: github.com/skyhook-io/radar. The MCP server is in the box; point your own agent at it and see if your numbers look like ours.

Your AI visibility number is lying to you

Daria Dovzhikova — Mon, 13 Jul 2026 12:15:08 +0000

I ran 1,790 measurements across five AI engines — for my own company and for a devtools category with real money in it. Most of what "AI visibility" dashboards report turned out to be an artifact. Here are the three mirages, and the four numbers worth tracking instead.

The buyer shift is real. G2's latest survey has 51% of B2B software buyers starting vendor research in AI chatbots more often than Google, and chatbots are now the single biggest influence on shortlists. Ahrefs measured what happens on the other side: when an AI Overview shows up, clicks to the #1 organic result drop by more than half.

So now 88% of marketers say they're optimizing for AI search. Ask how they're measuring it and the room gets quiet — most brands don't track AI-search performance at all. The GEO subreddits are full of agency owners asking each other what to even put in a monthly client report.

I've spent the past six weeks measuring instead of asking. Two audits: one on my own company (800 prompts across four engines, run twice, five weeks apart), one on the web-scraping category — Firecrawl, Apify, Bright Data, ScrapingBee, and 22 other vendors (198 buyer queries × 5 surfaces, 990 cells, validated against an independent 10,000-mention dataset).

The measuring was the easy part. The work was not fooling myself. Three mirages, in order of how much money they'll cost you.

Mirage #1: The branded-prompt artifact

My own dashboard told me GTM Labs was ranked #1 on every AI platform, with 35–37% visibility. A number like that goes straight into a board deck.

It was fiction. The mechanism matters, because your GEO tool probably has the same one built in.

My prompt set had 40 prompts. Sixteen of them mention my brand by name — comparison prompts ("GTM Labs vs Kalungi"), evaluation prompts ("is GTM Labs any good"). On those, the engines recognize the brand nearly every time: 58 out of 64 responses. That near-perfect recall score gets averaged together with everything else, and suddenly the aggregate says 35% and #1.

Strip out every prompt that feeds the model my name — leave only the questions a real buyer asks before they have a shortlist, like "best fractional PMM for devtools" — and my organic score is 0 out of 96.

Not 35% — zero. The engines know who I am when asked directly and never think of me unprompted. Those are two different problems, and the branded average hides the one that matters.

So the test for any AI-visibility report, whether it came from a $300/month tool or an agency: does it separate branded prompts from organic ones? If it doesn't, you're reading a recall test dressed up as a discovery measure, and recall was never the hard part.

One consolation from my zero: total organic mentions across all five competitors I track fell from 11 to 6 between runs. Nobody owns these queries yet. The floor is low and winnable — which is why measuring it honestly matters.

Mirage #2: The single-surface headline

The Firecrawl audit gave me my favorite wrong headline of the year, and I wrote it myself.

First pass: Firecrawl is the #1-cited vendor in web-data tooling. True — on Perplexity, at 25% share of citations, well ahead of Apify.

Then the independent dataset arrived. It's ~90% Google AI Overviews, and there Firecrawl is #3 at 20%, behind ScrapingBee at 31% and Bright Data at 28% — the incumbents with a decade of ranked content behind them. On ChatGPT search: a three-way tie for third, at 14%.

Same vendor. Same month. #1, #3, and #3, depending on which engine you ask.

The engines have different supply chains. Perplexity leans hard on what developers currently recommend to each other (Reddit, recent listicles). AI Overviews inherit a decade of Google rankings. ChatGPT search sits somewhere between. A one-number "AI visibility score" averages across sources that disagree with each other and tells you nothing you can act on.

When a tool or a report quotes you a single number, the question is always: which engine, and on which prompts? If the answer takes more than one sentence, the number was marketing.

Mirage #3: llms.txt

On June 1st I deployed the full on-site AI-optimization stack on my own site: llms.txt, llms-full.txt, JSON-LD on every service page, entity schema. The exact checklist every GEO thread recommends.

Thirty-four days later I re-measured. Organic visibility went from 1/96 to 0/96.

That was the honest prediction all along — a top comment in one of the GEO subreddits put it better than any vendor deck: everyone has implemented llms.txt; no crawlers are requesting it. My server logs agree.

Keep the file. It costs nothing, it's tidy, it may matter someday. But treat it as plumbing. The engines cite what other people say about you, and my on-site deploy was me telling the engines about myself. They were not interested. Fair enough — neither are buyers.

What actually moves citations

The Firecrawl data shows where the leverage lives, and it's old-school.

Firecrawl's citation gaps aren't random — 44 queries where a rival is cited and Firecrawl isn't, clustering into one coherent theme: hard-target scraping (anti-bot, Cloudflare, behind-login). On those, engines route buyers to proxy specialists or Playwright tutorials. Citation share on gap themes: 12.6%, versus 23.7% on home turf. The engines have compressed the product into one sentence — "URL-to-markdown for AI agents" — and they hand everything outside that sentence to someone else.

LLMs don't read your feature list. They compress you into one job. Whatever sentence the internet repeats about you most often is your product, as far as the engines are concerned.

And the root cause is almost boring: on 6 of the 9 gap keywords, Firecrawl is absent from Google page 1 entirely. The AI-citation gap mirrors the organic-search gap nearly one-to-one. Engines can't cite what doesn't rank.

The sources that do rank on the gap-theme results: Reddit (27 appearances), GitHub (12), Medium (9), and indie listicles — above any vendor's own blog in nearly every case. Your blog is not in the citation supply chain. The r/webscraping answer, the runnable GitHub cookbook, the third-party "best X for Y" listicle: that's the supply chain.

For all the noise about GEO being a new discipline, the machinery underneath is mostly the old one — rank, get referenced, be the thing communities recommend. What's new is that the interface stopped sending you the click, so the only thing left to win is the citation.

The Four Numbers

If you run a devtools company — or you're the first marketer at one, staring at a "track your AI visibility" vendor pitch — this is the monthly report I'd actually run. Four numbers, one discipline.

1. Organic citation share, per engine, unbranded prompts only.
Build a prompt set from questions buyers ask before they know you exist. Score each engine separately — you now know why. This is the number that tracks discovery, and it will be humbling. Mine is zero. I just published it anyway, which tells you how rare honest baselines are.

2. Branded recall rate — on its own line, never averaged in.
"Do the engines know you when named?" is worth tracking — misses here point to entity work (schema consistency, Wikidata, third-party profile completeness). It's the cheapest fix on this list. It just can't be allowed anywhere near number 1.

3. The gap list, weighted by CPC — not volume.
Every query where a competitor is cited and you aren't, ranked by what the click is worth. "Best web scraping API" gets 140 searches a month and looks like a rounding error in a volume report. It carries a $40 CPC — the market telling you exactly what a citation there is worth. Volume-sorting your gap list deprioritizes the only queries that pay.

4. The citation supply chain.
For your gap queries: which domains do the engines actually cite? That list is your content-placement roadmap. If it's Reddit, GitHub, and two listicles — and it will be — then that's where the work is, not on your own blog.

Plus one discipline that isn't a number: measure monthly, and respect small samples. At my scale, a single stochastic mention is the difference between "up 100%" and zero. A trend needs three points before it's a trend. Anyone selling you daily AI-visibility tracking is selling you noise with a subscription.

The kicker

The entire rig behind this piece — 198-query category audit across five surfaces, plus independent validation — costs about $15–30 per sweep in API calls, plus $2.15 for the validation dataset. The scripts are boring Python.

That's less than a day of most GEO tools' monthly price, and it produces the four numbers most of them don't show you — including the one that told me my own headline number was a mirage.

Your buyers moved into the chat window, and measuring whether you exist there is now part of the job. Just make sure you're measuring the moment before they know your name — because right now, that moment belongs to almost nobody, and it's for sale.

If you'd rather run it than read about it

I open-sourced the honest core of this method as a zero-dependency Python script. It scores organic (non-branded) visibility per engine, keeps branded recall on its own line, and prints the citation supply chain — the four numbers above, on your own machine, for a few cents a run:

github.com/dovzhikova/ai-visibility-scorer

python3 ai_visibility.py --brand "Your Product" --domain yourproduct.com \
  --category "what your buyers actually shop for" \
  --competitors "Rival:rival.com"

Want the moment-before number for your own product? Start with the free AI Visibility Checker — it takes two minutes. If the number stings, that's what the GTM Diagnostic is for.

Every web-data tool says it's "built for AI." I asked the AI.

Daria Dovzhikova — Thu, 04 Jun 2026 13:43:32 +0000

I ran 198 real buyer questions through five AI engines, then validated against an independent dataset, to find out who actually gets cited for web scraping. The scoreboard surprised me twice — once when my own headline turned out to be wrong.

Rank trackers tell you where you stand on Google. Nobody can tell you where you stand inside ChatGPT, Perplexity, or an AI Overview — which is inconvenient, because that's where your buyers moved.

So I built the tracker. Then I pointed it at a category with real money in it: web-data tooling — Firecrawl, Apify, Bright Data, ScrapingBee, and 22 other vendors who all describe themselves as the infrastructure layer for AI. Fine. Let's ask the AI.

To be clear: Firecrawl didn't ask for this. I picked them because they're the category's momentum story — the "everyone's favorite scraping tool for LLMs" — which makes them the perfect test of a question I keep asking clients: does AI-era buzz convert into AI-era citations?

Mostly yes. Partly no. The "no" is where it gets interesting.

The method (so you can argue with it)

198 queries a developer evaluating web-data tooling actually asks, across 8 intent clusters, each scored intent_weight × revenue_proximity. Not "what is web scraping" filler — comparison, pricing, jobs-to-be-done, "best X for Y" queries.
5 surfaces: Perplexity-Sonar and GPT-4o-search (both return real citations), Claude and Gemini (no live browsing — they measure framing, who the model names unprompted), and a live web-SERP layer. 198 × 5 = 990 cells, zero errors.
Independent validation: DataForSEO's LLM-mentions corpus (~10,000 mentions, ~90% of them Google AI Overviews), plus live Google SERPs and Ads volume/CPC data. Two datasets that don't know about each other.
Counting is query-coverage — a vendor scores max once per query per surface, so one heavily-cited listicle can't inflate anyone's numbers.

None of this is vibes. Re-run scripts exist.

Finding 1: "Who leads AI citations" depends entirely on which AI you ask

My first headline was: Firecrawl is the #1-cited web-data vendor. True on Perplexity — 25%, comfortably ahead of Apify at 15%.

Then the independent dataset arrived and corrected me. On Google AI Overviews, Firecrawl is #3 at 20%, behind ScrapingBee (31%) and Bright Data (28%) — the two incumbents with a decade of content and backlinks behind them. On ChatGPT-search, Firecrawl is in a three-way tie for #3 at 14%, behind Apify at 21%.

Same vendor. Same month. #1, #3, and #3 — depending on the engine.

The lesson generalizes: any single-surface AI-visibility number is closer to marketing than measurement. Perplexity skews toward what developers currently recommend to each other. AI Overviews skew toward what has ranked on Google for years. If a vendor (or a tool selling you "AI visibility tracking") quotes you one number, ask which engine — the answer is the whole story.

Finding 2: 100% of the branded queries, ~0% of the moment before

Firecrawl wins effectively every branded query in the set — comparisons, "is it worth it," pricing, alternatives. It's named in 143 of 198 queries, the most of any vendor. When someone already knows the name, the engines have nothing but nice things to say.

The problem is the moment before. On unbranded, high-intent questions — the "how do I actually solve this" queries where a buyer doesn't have a shortlist yet — there are 44 clean gaps where a rival gets cited and Firecrawl simply isn't in the room.

Reputation: excellent. Discovery: leaking. These are different problems with different fixes, and almost everyone lumps them into one "brand awareness" line item.

Finding 3: The engines have quietly typecast the product

The 44 gaps aren't random. They cluster into one coherent theme: hard-target scraping — anti-bot evasion, Cloudflare, behind-login, scraping at scale without getting IP-blocked. On those queries, the engines route buyers to proxy specialists (Bright Data, Oxylabs, ScraperAPI) or to DIY Playwright tutorials. Structured e-commerce extraction goes to Apify and Octoparse.

The numbers: Firecrawl's citation share is 12.6% on gap themes vs 23.7% on home turf. The engines have typecast it as "the URL-to-markdown tool for AI agents" and hand everything harder to someone else — regardless of what the product can actually do.

This is the part I'd tattoo on every DevTools positioning doc: LLMs don't read your feature list. They compress you into one job. Whatever sentence the internet repeats about you most often is your product, as far as the engines are concerned.

Finding 4: The AI gap is an SEO gap wearing a trenchcoat

Here's the root cause, and it's almost boring: on 6 of the 9 gap keywords, Firecrawl is absent from Google page 1 entirely. The AI-citation gap mirrors the organic gap nearly one-to-one.

Engines can't cite what doesn't rank. For all the talk about GEO being a new discipline, the supply chain underneath is mostly the old one. Which means the fix is content and ranking — not product, not press releases, and definitely not adding "AI-powered" to the homepage again.

Bonus demand-math: the gap keywords look worthless in a volume report — "best web scraping api" gets 140 searches a month. It also carries a $40 CPC, which is the market telling you exactly what a citation there is worth. Weight AI-visibility work by CPC and intent, not volume, or you'll deprioritize the only queries that pay.

Finding 5: The citation supply chain is not your blog

Across the gap-theme SERPs and the LLM corpus, the sources engines actually quote are Reddit (27 appearances), GitHub (12), Medium (9), YouTube, and a handful of indie listicles — consistently ranked above any vendor's own blog. In the LLM-mentions corpus, YouTube and Reddit are the single most-cited domains on most queries.

You don't out-write this from your own domain. The work is being genuinely useful in the places engines read: answering the Cloudflare question on r/webscraping, shipping the runnable GitHub cookbook, getting onto the listicles that own the $15–40 CPC heads. Unglamorous, compounding, and almost nobody's job description.

What this means if you run a DevTools company

Measure share-of-citation per engine, not "AI visibility." The per-engine split is the diagnosis. (Perplexity-strong + AIO-weak = community loves you, authority hasn't caught up. The reverse = the opposite problem.)
Separate recall from discovery. Run branded and unbranded query sets independently. Winning your own name tells you nothing about the moment before.
Find your typecast sentence. Ask the engines 20 unbranded jobs-to-be-done questions and read what job they give you. If it's narrower than your product, that's your positioning backlog.
Fix the organic gap first. Page-1 absence and citation absence are the same defect.
Budget for the supply chain. Reddit, GitHub, YouTube, listicles — third-party surfaces beat your blog for citations, every time we've measured it.

The harness behind this is reusable — 198 queries, 5 engines, independent validation, about a day of work to point at any category. I run it monthly. The first run is the painful one; after that it's a scoreboard.

Firecrawl, if you're reading: you're winning the engine developers trust and trailing the one everyone's mom uses. Defend Perplexity. Go win Google. You know where to find me.

Daria Dovzhikova runs GTM Labs — developer-first GTM for DevTools, security, and AI/ML startups, delivered as a human-in-the-loop agent fleet. The AI-visibility harness from this piece is the same one used on client work. gtm-labs.co

How to hire a developer-first PMM (and when you actually need one)

Daria Dovzhikova — Mon, 01 Jun 2026 12:04:14 +0000

Most early-stage devtool founders I talk to have the same problem and reach for the wrong fix. The product is good, engineers who find it like it, and yet nobody can explain — in one sentence — what it does and who it's not for. So growth is whatever happens to leak out of the founder's Twitter.

The instinct is to hire "a marketer." The better question is which marketer, and whether you need one at all yet. Here's the honest version, including when the answer is "not us, not yet."

What "developer-first PMM" actually means

Product marketing (PMM) owns the boring-but-decisive middle of go-to-market: positioning (what it is, who it's for, why it's different), launches (turning a shipped feature into a thing people notice), competitive intelligence, and sales/DevRel enablement (arming the people and pages that do the convincing).

"Developer-first" changes how you do all of that, because the buyer is an engineer:

They distrust marketing by default. A benefit-soaked landing page ("10x your velocity!") reads as a red flag, not a hook. You win on precision — what it does, the tradeoff, the code — not persuasion.
The funnel is inverted. Adoption happens before the sales conversation. They try the free tier, star the repo, ship something. Your job is to remove friction from that self-serve path and then figure out which accounts to actually talk to. MQLs are mostly the wrong unit; qualified usage is the right one.
Docs are the highest-intent marketing surface you have. Your quickstart converts harder than any campaign. PMM that never touches docs/DX is ignoring the actual conversion page.
You arm champions, not personas. Someone inside the company has to sell your tool to their team and their security reviewer. Your best "sales collateral" is a page that helps them do that.

None of this is exotic. It's classic PMM rigor applied to an audience that rewards technical credibility over messaging polish.

The four ways to buy it — and when each is right

1. In-house full-time PMM. Right when you have enough launch cadence and surface area to keep a senior person busy and a leader who can manage them. Wrong as your very first marketing dollar, because a great PMM with no system around them spends month one building the system instead of doing the work.

2. Fractional PMM (a senior practitioner, part-time on retainer). The sweet spot for most seed–Series A devtools. You get someone who has positioned products for engineers before, who ships — the messaging doc, the launch, the comparison pages — not just a strategy deck. Cheaper than a full hire, faster than recruiting, and they don't need a team underneath them to be useful.

3. Fractional CMO. Buy this when you need direction over a team that already exists — someone to steer several marketers. The classic failure mode: a seed company hires a fractional CMO for strategy, gets a great 90-day plan, has nobody to execute it, and concludes "fractional doesn't work." It worked; they bought the wrong half. At pre-$1M ARR you almost always need execution more than a title.

4. Agency. Good for a defined, repeatable output (content production, paid, design). Riskier for positioning a technical product, because the team usually isn't embedded enough to develop an opinion an engineer would respect. If you go this route, make sure someone there has actually sold to developers — not just "B2B SaaS."

Five questions to ask any candidate (fractional or full-time)

"Walk me through a developer tool you've positioned. What did the one-sentence pitch become?" You're listening for whether they can compress a technical product into something sharp, not whether they can recite framework names.
"How would you market this without generating a single traditional lead?" A developer-first marketer should be comfortable with signups, usage, community, and docs as the engine. If they immediately reach for gated whitepapers and an MQL target, keep looking.
"Where do docs and DX fit in your remit?" "Not my job" is a yellow flag for devtools.
"Show me something you shipped, not a deck you presented." Positioning is only real once it's in the product, the site, and the enablement. Ask for artifacts.
"What's a marketing tactic that works great for normal SaaS and quietly fails on engineers?" Tests whether they actually understand the audience or just relabeled a generic playbook.

An honest map of the space

I run GTM Labs — developer-first PMM and GTM for devtools, cybersecurity, and AI/ML startups — so take this as one practitioner's read, not a neutral ranking. But the space is small and worth knowing:

Independent developer-marketing consultants & studios: people like Markepear (Jakub Czakon's curated list is the best map of this niche), Emily Omier (positioning), Nick Moore, Zach Goldie, Fletch (PMM), Draft.dev and Hackmamba (technical content). Strong if you want a specific function done well.
Fractional PMM / GTM (positioning + launches + enablement, embedded): the slot GTM Labs sits in — senior practitioner who ships, for teams with 0–5 marketers.
Fractional CMO networks (Kalungi, MarketerHire, Right Side Up, Chief Outsiders): broader B2B-SaaS marketing leadership. Excellent operators; just confirm devtools fluency, because most of their reps come from general SaaS, e-comm, or fintech.
DevRel-specific (DevRel.Agency and others): when the gap is community and developer advocacy more than positioning.

The point isn't "pick GTM Labs." It's that "marketing help" is four different jobs, and matching the shape of your gap to the shape of the hire is the whole decision.

A rule of thumb to leave you with

Write one sentence before you sign anyone: "In 90 days, this will be physically different, and this specific person will have done it." If you can't fill in both halves, you're not ready to hire — you're ready to scope. The best fractional engagements start with someone helping you write that sentence honestly, then doing the part that's theirs.

Daria Dovzhikova spent 12 years in developer products — 7 as PMM at JetBrains, then GTM at Lightrun and Odigos — and now runs developer-first product marketing at GTM Labs. She's running the State of Developer-Tools PMM 2026 survey — the first open dataset on how PMM actually works inside devtools companies.

The Developer Tool Positioning Framework That Actually Works

Daria Dovzhikova — Wed, 04 Mar 2026 10:50:34 +0000

You built something great. It solves a real problem. The code is clean, the docs are decent, and you've been using it yourself for months.

So why is nobody signing up?

The problem isn't your product. It's your positioning.

Why Generic Positioning Advice Fails for Dev Tools

Most positioning frameworks are designed for consumer apps or enterprise SaaS. They assume your buyer sees an ad, visits a landing page, and makes a purchase decision in a single session.

Developers don't work that way.

A developer's evaluation process looks more like this:

They hear about your tool from a peer or see it on HN/Reddit
They check your GitHub — stars, commit frequency, open issues
They skim your README (not your landing page)
They check your docs — if the getting-started takes more than 10 minutes, they're out
They try it in a side project, not production
Weeks later, they might bring it to their team

Your positioning has to work at every stage of this process, not just on a homepage hero section.

The 4-Layer Positioning Framework

Here's the framework I use for every dev tool I work on.

Layer 1: The One-Liner

This is the sentence that appears everywhere — your GitHub description, your Twitter bio, the first line of your README.

Formula: [Tool name] helps [specific developer type] [do specific thing] [without specific pain]

Bad example: "A cloud-native observability platform for modern infrastructure"

Nobody knows what that means. It sounds like every other tool in the space.

Good example: "Find production bugs in 30 seconds — not 30 minutes"

The difference: the good version describes a transformation, not a category. Developers don't want an observability platform. They want to find bugs faster.

Exercise: Write 10 one-liners for your tool. Show them to 3 developers who've never seen your product. The one they immediately understand is your winner.

Layer 2: The Pain Stack

List every pain point your tool addresses, then rank them by how acutely a developer feels them day-to-day.

The top pain isn't always what you think. You might have built the tool to solve Problem A, but your users keep telling you Problem B is why they adopted it.

Structure your pain stack:

Pain	Frequency	Intensity	Who feels it most
Debugging takes 30+ min	Daily	High	Backend devs
Alert fatigue from noisy monitoring	Daily	Medium	On-call engineers
Onboarding new devs to the codebase	Monthly	High	Team leads
Compliance audit logging	Quarterly	Low	DevOps leads

Lead with the pain that's highest frequency AND highest intensity. That's your positioning anchor.

Layer 3: The Competitive Frame

You don't exist in a vacuum. Developers are either using a competitor, using a hack/workaround, or doing nothing.

Each competitive frame requires a different positioning angle:

vs. a direct competitor: "Like [competitor], but [key difference that matters]"
Example: "Like Datadog, but you can self-host it and it costs 90% less"

vs. a workaround: "Stop [painful workaround], start [better outcome]"
Example: "Stop grep-ing through logs. Get the stack trace in one click."

vs. doing nothing: "You don't know what you're missing until..."
Example: "Teams using [tool] ship 3x faster. Here's why."

Layer 4: The Proof Layer

Developers are deeply skeptical of marketing claims. Your positioning only works if it's backed by proof they trust.

Proof that works for developers:

GitHub stars and contributor count
Benchmark results (with reproducible methodology)
Named companies using it in production
Architecture blog posts showing how it works under the hood
"Built with" badges on open source projects

Proof that doesn't work for developers:

"Trusted by 10,000+ developers" (says every tool ever)
Stock photos of people at computers
Logos of companies who signed up for the free tier
Testimonials without names or context

Putting It All Together

Once you have all four layers, assemble them into a positioning document that the entire team can reference:

ONE-LINER: [Your one-liner]

PRIMARY PAIN: [Top pain from your stack]

COMPETITIVE FRAME: We're the [positioning] for [audience]

PROOF: [Your 3 strongest proof points]

This document should fit on a single page. If it doesn't, you're overcomplicating it.

Every piece of content you create — landing page, README, blog post, social post — should align with this document. If it doesn't, you're diluting your positioning.

The Toolkit

I've taken this framework, along with launch planning, pricing strategy, community growth, content planning, and channel strategy frameworks, and packaged them into 6 fill-in-the-blank templates.

It's called the DevTools GTM Toolkit — $25, one-time purchase, instant access. The Positioning Canvas walks you through all 4 layers above with 8 specific prompts that force clarity.

If you're a dev tool founder figuring out your go-to-market, or a first marketing hire at a developer tools company, these are the exact frameworks I'd hand you on day one.

What's the biggest positioning challenge you've faced with a dev tool? Drop it in the comments — I'll give you a specific suggestion using the framework above.

Hi, I'm Daria — I Help Dev Tool Founders Figure Out Go-to-Market

Daria Dovzhikova — Tue, 03 Mar 2026 16:45:24 +0000

Hey Dev.to 👋

I'm Daria — a product marketer who's spent most of her career figuring out how to bring developer tools to market without making developers cringe.

I've worked on go-to-market across a range of dev-facing companies:

JetBrains — the company behind IntelliJ, PyCharm, and Kotlin. Marketing to developers who make developer tools is a humbling experience.
Huawei — Enterprise-scale GTM where "move fast and break things" is not an option.
Lightrun — real-time debugging platform. Positioning a new category of tool that developers didn't know they needed yet.
Odigos — open-source observability. GTM in a space where your competition is literally free, and your users can fork your product.

Each one taught me something different about what works — and what absolutely doesn't — when your target user can read your source code.

What I'll write about here

Developer marketing is a weird niche. Most marketing advice assumes your buyer responds to urgency, social proof, and emotional triggers. Developers... don't. Or at least not in the ways marketers expect.

So I'll be writing about the stuff I wish someone had written when I was figuring this out:

Positioning dev tools — why "we're like X but for Y" rarely works with technical audiences
Pricing strategy — the unique dynamics of free tiers, open-source alternatives, and developer willingness to pay
Launch planning — what a realistic launch looks like when you're a solo founder or a team of three
Community-led growth — how to actually contribute to communities without being "that marketing person"
Content that converts — the difference between content developers bookmark and content they ignore

My angle is practitioner, not pundit. If I haven't done it myself, I'll say so. If a framework didn't survive contact with a real launch, it won't show up in my posts.

What I'm building right now

After rebuilding the same positioning, pricing, and launch planning frameworks from scratch at every new company, I finally packaged them into the DevTools GTM Toolkit — 6 templates, 3 frameworks, and 6 checklists designed for dev tool founders who need structured GTM without hiring a consultant.

Come say hi

I'd love to connect with other folks building or marketing developer tools. If you're:

A solo founder trying to get your first 100 users
A developer who accidentally became "the marketing person" at your startup
Someone who's ever stared at a blank positioning doc wondering where to start ...we'll probably have a lot to talk about.

Drop a comment, or find me on LinkedIn. First post coming soon — a positioning framework built specifically for how developers evaluate tools.

See you around ✌️