On this page
I have spent the last 4 years directly or indirectly working on getting more eyeballs (and signups) from engineers and software developers.
These are the things that I have noticed that make marketing to engineers ✨ different ✨ than marketing to a non-technical audience.
1. Keep it raw
The core difference between marketing a devtool to engineers vs any other product is that the builder and the user both share the same persona.
A simple contrast to this is buying a washing machine where you don't think about motors or drums. You only care about the results and thus want to see only that.
And that is why marketing for such cases involves a process of carefully curating, synthesizing, and presenting information that makes your brand look like the undisputed choice.
When you apply the same approach to marketing a devtool, you only get raised eyebrows, doubts, and an audience who choose to ignore you for trying to make them feel manipulated.
Let developers draw their own conclusions
Instead what you need to do is give them the raw facts, benchmarks, and insights into how you engineered your product and let them make their own conclusions.
A good example of this is PlanetScale.
In its Postgres comparison with Supabase, PlanetScale reports roughly 17,000 queries per second against roughly 5,000 in its TPCC-like test. It shows the conditions: about 500 GB of data, 32 and 64 concurrent connections, and five-minute runs. PlanetScale used a 4-vCPU, 32-GB M-320 with local NVMe storage; Supabase used an 8-vCPU, 32-GB 2XLARGE with EBS increased to 12,000 IOPS. The reader can see that the hardware differs.
The page includes throughput over time and p99 latency, plus commands to reproduce the test. These are PlanetScale’s measurements for that setup. Its methodology post explicitly says a benchmark cannot tell you how your own workload will behave. A developer can inspect the configuration, rerun it and decide whether the comparison matters for their application.
Be opinionated (but back it up)
Keeping it raw doesn't mean you cannot have an opinion. You should have a strong opinion about the problem you are solving and why your approach is better. Just be ready to explain it beyond saying your product is "blazingly fast".
That is what makes the PlanetScale example interesting to me. They make a performance claim and give you the setup and commands to question it. Now you have something specific to discuss, agree with, or prove wrong.
Sam Lambert, PlanetScale's CEO, takes it further with this jab at Supabase users: "for the supabase users out there the µ means microsecond.
2. Your product is your best marketing asset
Developers are the best marketers once you unlock a magical experience for them. They won't shut up talking about it because developers are, by default, builders.
They will go build something with it, and once you build something using something, you want to talk about it. There is this inner urge. That is what I think drives most of the word of mouth for all these tools.
One good example of this was the OpenClaw moment. It was a step up from the existing alternatives at that time. People quickly caught on, started building their own things on top of it, and then couldn't stop talking about it because it makes them feel relevant and smart in front of the others.
3. Engineers listen to engineers (not growth or marketing folks)
Who is talking about your product matters just as much as what they are saying.
If I am evaluating a devtool, I would rather hear from the person who built it. I can ask why they made a decision, what breaks, or where the product will not work well. And they can actually answer those questions.
The order I think of is: co-founders and CTOs first, then engineers, then DevRel, then growth and marketing. And it changes how I would think about hiring for a devtool company.
Boat.dev is a good example of this. Its founder, Anicet Nougaret, talks about the product with a lot of pride. In his benchmark launch, he makes a bold performance claim, shares reproducible benchmark code, and gets into the details when people question the numbers.
You get to see the person behind the claim answering for it. That is much more interesting to me than a company account repeating the same claim in five different ways.
And that all converts to revenue:
The same thing shows up at big labs like Anthropic or OpenAI.
At Anthropic, Thariq's interactive-questions launch is followed by his personal note that it is his first shipped feature and that a lot of care went into it.
At OpenAI, Tibo's personal product-use example describes his dots helping coordinate work with his CPA. Replies include another user's concrete workflow and questions about accessing multiple dots. His message-editing release post is candid about how long shipping took.
This is what I want more devtool companies to do. Give the people building the product room to talk about it. Let their excitement come through, and let them answer the difficult questions too. Growth and marketing can help more people find that conversation.
That takes me back to the washing machine example. Most of the time, I just want to know if it will clean my clothes. With a devtool, I am choosing something I will build on and eventually have to troubleshoot.
I want to understand the decisions underneath the promise. Hearing from the people who made those decisions is part of how I evaluate the product.
So give me something useful to inspect, an opinion I can argue with, and a product that makes me want to build. I can draw my own conclusion from there.