How to market a devtool when the category doesn't exist?

Open Ahrefs for an established devtool category and you have somewhere to start. You can see what developers search for, which competitors rank, what comparison pages get traffic, and which keywords might be worth paying for.

Now imagine opening it and finding almost nothing.

You can still see signs of the problem. Developers are hacking together solutions for it, complaining about it on Reddit, asking questions in Discord and Slack communities, or building internal tooling around it. They just are not searching for the category you want to sell them yet.

A lot of devtool companies we know today started somewhere around there.

When Linkerd was getting started, developers already had the problems we now associate with a service mesh: service-to-service communication, retries, reliability, observability, and security across increasingly complex microservice architectures. In 2017, William Morgan published an article explaining what a “service mesh” was and why developers might need one. Linkerd itself had already existed before that terminology became widely understood.

Netlify had a similar language problem. Developers were already building sites with JavaScript, APIs, static site generators, Git-based workflows, and decoupled backends. Mathias Biilmann gave that architecture a name: JAMstack. Netlify then spent years talking about the architecture, the developer workflow, and the ecosystem around it.

You can see the same thing happening much faster in AI infrastructure. The Langfuse founders were building LLM applications and kept running into the difficulty of taking them from demos to production. They worked with other YC companies on an early product for tracing and understanding those applications while LLM observability was still taking shape as a category.

Browserbase started from another emerging problem. Developers could automate a browser with Playwright or Puppeteer, but running browsers reliably for AI agents created a new infrastructure problem. Browserbase had to explain why developers would need dedicated browser infrastructure in the first place.

This is what I want to talk about in this article: how do you market a devtool when the category barely exists, search demand is close to zero, and developers are still using other words to describe the problem?

You cannot rely heavily on the usual demand-capture channels yet. There may be no meaningful category keyword to rank for, no comparison searches to intercept, and no established group of developers already looking for what you built.

So you have to create the first few pockets of demand yourself. I am not going to spend much time on technical content or documentation here because you need both whether you are entering an established category or creating a new one.

I want to focus on distribution: where you show up, which channels help developers discover the problem and product, and how you figure out what is actually bringing the right people in.

Start with the founder’s existing audience

If you already have an audience on X, I would start there. You already have developers, founders, maintainers, and people working on adjacent problems following you. I would use that distribution before spending time building a company account from zero.

Talk about the problem that made you build the product.

Zeno Rocha did this well around React Email and Resend. React Email gave developers an open-source way to build emails with React, while Zeno was already talking publicly about the developer experience of sending email. When Resend came along, there was already an audience familiar with the problem and the work he was doing around it.

If you are building an agent debugging product, I would do the same around that problem.

Show a failed agent run and explain what went wrong. Share a debugging workflow your team uses. Show the script you wrote because the existing tools were not enough. Publish a pattern you noticed after looking at hundreds of failed tool calls. If you have a benchmark or an interesting piece of data, share that too.

You are giving developers repeated exposure to a problem they may already have. I would keep an eye on what happens after each post. Impressions and replies tell me whether the topic is getting attention, but I also want to see developers opening the repo, reading the docs, joining the waitlist, and trying the product.

When one angle keeps bringing the right developers in, I would keep talking about it from different sides.

X gives you a way to build awareness around the problem. Once I have people paying attention, I would take the same problem to Reddit and see what developers say when they have fewer reasons to be nice about it.

Take the problem to Reddit

I would use Reddit to get sharper feedback on the problem and find early users, using what we've learned from marketing devtools on Reddit.

Start with the communities where developers already talk about the problem. If you are building AI infrastructure, that could be subreddits around agents, RAG, local LLMs, machine learning, or the frameworks your users already use.

I would also use Octolens to track the problem across Reddit instead of checking communities one by one.

For an agent debugging product, I might track agent debugging, tool call failures, agent tracing, agent retries, and the names of tools developers already use. I would also track adjacent phrases that developers might use before they have a name for the problem.

Read those threads before you start posting. I want to see how developers describe the problem, what they have already tried, which tools they mention, and what they still cannot solve.

Then join the conversations where you can help. If someone is struggling to debug failed tool calls and I have dealt with the same problem, I would explain what we found and how we handled it. If the product can help, I would mention it and give them a way to try it.

I would also create my own posts once there is something usable. I would show the problem, explain what we were doing before, show what we built, and ask developers to try it.

LocalAGI is a good example. The founder launched it in r/LocalLLaMA, explained how it let developers build agent workflows on top of local models, linked the GitHub repo, and asked the community what they would build and what feedback they had.

The useful part came in the comments. Developers asked for a demo video and a clearer tutorial for installing and configuring the stack. The founder replied in the thread, shared the setup commands, and said they were already working on better onboarding material.

That is the kind of feedback I would look for. If developers tell me they already solve the problem another way, I want to understand how. If they keep asking the same setup question, I would fix the onboarding. If they cannot see why they need another tool, I would look at how I am explaining the product.

Then I would update it and try again. If developers start joining the waitlist, opening the repo, or using the product, I have enough signal to try Hacker News or Product Hunt.

If they do not, I would keep improving the product and testing it through X and Reddit until I have something developers want to use.

Launch it where developers already look for new tools

Once you have a usable product and some early signal from X and Reddit, I would start putting it on launch platforms.

I would try Hacker News first. Show HN works well when people can actually use what you built. Keep the title simple, link directly to the product, and explain the technical problem in the comments.

This is the kind of the format I mean:

Hacker News is unpredictable, so I would not make the whole launch depend on it.

I would also submit the product to DevHunt. It is built specifically for developer tools, which makes it a much better fit for an API, SDK, CLI, infrastructure product, or open-source project than a general startup directory.

Then I would look at Product Hunt and Peerlist Launchpad. Product Hunt gives you a larger general tech audience and lets you prepare the screenshots, demo, positioning, and maker story before launch. Our Product Hunt launch guide covers gallery strategy and launch-day ops.

Peerlist has a much more developer-heavy audience, so I would use it when the people I want using the product are engineers and technical builders.

You can also test smaller launch platforms such as Uneed. If the product is still in early access and you are mainly trying to build the first waitlist, BetaList can make sense earlier in the process.

I would spread these launches out instead of publishing everywhere on the same day. Each launch gives you another chance to see which message gets developers interested and what they do once they reach the product.

I would track repo visits, quickstart starts, signups, API keys created, installs, and actual usage.

If Hacker News goes nowhere but DevHunt sends 30 developers who install the SDK, that tells me much more than the number of upvotes on either platform.

If none of them bring the right people in, I would go back to X and Reddit, improve the product or how I explain the problem, and launch again when I have something stronger.

Use email to get the first signups

I would start doing outbound ASAP if I'm already see early signs of traction.

Email is one of the cheapest channels you can test. You do not need an existing audience, a large ad budget, or months of search traffic before you can put the product in front of the right company.

I would keep the list small and specific. By now, X, Reddit, and your launches should have given you a better idea of who has the problem. Use that to find companies showing the same signals.

If you are building an agent debugging product, I might look for companies hiring AI engineers, publishing posts about agents, maintaining agent-related repositories, or already using frameworks such as LangGraph.

Then I would find the person closest to that work and send them a short email. I would mention why I reached out, the problem we are working on, and give them an easy way to try the product.

For example, if I saw that their engineering team was building multi-step agents with LangGraph, I could send them a short note showing how we debug a failed run and link directly to the product or quickstart.

If the product is self-serve, I want them to sign up and use it. If it needs more explanation, I can offer to walk them through it.Then I would watch which companies sign up, which roles respond, and which message gets people into the product.

If I send 100 carefully selected emails and 10 developers try the product, I have something useful to build on. If nobody responds or signs up, I would look at the audience, the message, and the product before sending another thousand.

Sponsor the X posts that already proved themselves

If one of your X posts is already getting replies, repo visits, docs visits, or waitlist signups from the right developers, I would put budget behind that post.

I would keep the original format. A founder post about a benchmark, a technical failure, a product demo, or something you learned while building will fit the feed better than a polished brand ad. X supports promoted text, image, video, and carousel posts, and promoted posts can still receive replies, likes, and reposts.

For the agent debugging example, I could sponsor a post showing one failed run and target people around terms such as Claude Code, LangGraph, OpenTelemetry, and the tools developers already use in that workflow.

I would test keyword audiences and follower-based audiences in separate ad groups so I can see which group sends better developers into the product.

I would keep the first test small. If the sponsored post sends developers into the repo, docs, waitlist, or product, I would keep running it. If it produces impressions and clicks without product usage, I would stop it and test another post.

I would use X Ads to extend the reach of a post that has already earned attention from the right audience.

Use events to put developers inside the problem

If the product needs more explanation than a post can give, I would test small technical events before paying for a large conference booth.

I would start with workshops, meetups, hackathons, or talks inside communities that already care about the problem.

If you are building AI infrastructure, that could mean an AI engineering meetup. If you are building platform tooling, I would look at DevOps, cloud-native, or platform-engineering groups.

The session should teach something developers can use. For the agent debugging example, I would rather run a workshop on tracing a failed multi-step agent than give a product presentation about “agent observability.”

The product can appear inside the workflow once people understand the problem.

Hackathons can work well when developers need to experience the product before they understand its value. Supabase still runs hackathons alongside Launch Week, where developers build open-source projects with the product over a fixed period and submit working demos.

I would keep the first events small enough that I can talk to the people using the product.I want to see where they get stuck, what they build, which integrations they ask for, and whether they continue using the product after the event.

A room of 40 relevant engineers who use the product can teach me more than a booth that collects hundreds of badge scans.

Once the workshop or meetup format starts producing product usage, I would repeat it in other communities and consider larger events from there.

Create more reasons to launch

Do not treat launch day as a one-time event. Kilo Code has launched on Product Hunt six times as the product expanded. It launched VS Code, JetBrains, Kilo Code Reviewer, updated versions of its IDE products, and most recently its iOS and Android apps. Several of those launches ranked #1 Product of the Day, Week, or Month.

That gives the team a fresh reason to get attention every time it ships something substantial.I would do the same for major releases, new platforms, important integrations, benchmarks, or open-source projects.

If the update changes what developers can do with the product, launch it again.

Retarget the developers who already know you

By this point, you should have enough traffic from search, X, Reddit, Hacker News, newsletters, events, and other channels to start retargeting with paid ads.

I would not put every site visitor into one audience. Someone who read a technical article is at a different stage from someone who opened your pricing page, read a migration guide, or started the quickstart.

I would split visitors by intent. For example, I might create separate audiences for people who:

• Read technical content.
• Visited product or use-case pages.
• Read comparison or migration pages.
• Opened the docs or quickstart.
• Visited pricing.
• Started signup but did not activate.

Google can build audience segments from the pages people visit and the actions they take on your site. You can then use those segments across Google campaigns, including Search, YouTube, Gmail, and Display.

I would use Meta for cheaper repeated exposure to people who already know the product. The creative could be a short demo, a technical clip, a customer example, or one of the problem-led posts that worked on X.

I would use LinkedIn when I want to reach the business side of the account. The Insight Tag can build audiences from page visits, button clicks, and form submissions, and LinkedIn lets you narrow those audiences using professional attributes.

The ad should match what the person has already seen.

1. If someone read a technical article, I might show them the product solving that problem.
2. If they visited an integration page, I would show the integration working.
3. If they read a comparison page, I might send them to a migration guide or customer example.
4. If they reached pricing, I would show proof from a company using the product in production.

I would exclude people who have already completed the action I am trying to drive. Then I would measure whether retargeting moves people further into the product.

If it brings developers back to create an API key, install the SDK, complete the quickstart, or reach first successful use, I would keep running it.

If it gives me more impressions and return visits without improving activation, I would cut it.

Where this all leads

Once you know which messages work and which channels are bringing in the right developers, the next step is to make that repeatable. These lessons from DevGTM experts are a good checklist for what to systemize.

You can build the capability internally or work with a technical marketing agency that already knows how to run developer content, distribution, paid media, community, events, and documentation together.

That is also the kind of work we do at Hackmamba. We help developer companies build and run those systems across the full developer journey.

The important part is that you are no longer guessing where demand might come from. You have enough signal to know what deserves more time and budget.