DEV Community: Daria Dovzhikova

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 ✌️