The four pillars of developer marketing with Kuba Czakon
Kuba Czakon's biggest heresy in developer marketing is rejecting the one-CTA-per-page rule. A developer once told him directly: show me the options and let me choose. That single comment reshaped how Neptune.ai builds its homepage.
Kuba Czakon is CMO of Neptune.ai, a metadata store for MLOps, and a former data scientist and professional chess player. He also runs the Developer Marketing Slack community and the Developer Marketer blog.
We get into his four pillars of developer marketing — don't persuade, understand where your specific developer persona actually spends their time, be present where they're already searching, and get out of the way so they can build — plus how he's applied each one at Neptune, his approach to SEO using the awareness-funnel framework, and why he treats his own marketing team like CEOs of individual investment bets rather than employees executing a plan.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
You've written an ultimate guide to developer marketing. How should we be thinking about it?
There are a few core principles, and I'm still learning and tweaking plenty of this, but some things seem clear. If there's anything I've learned marketing to devs, it's don't try to persuade them — they don't trust you and don't believe you can persuade them, so trying actually loses you ground. The better approach is to educate, enable, and inspire. Devs are builders, and when they're looking for tools, they want to build better and faster, so everything flows from that first principle.
What's the second pillar?
Understand who your developers actually are and where they are. It sounds simple, but people bucket all developers into one persona when a machine learning engineer or data scientist is a completely different persona from a senior Java developer at a German enterprise. They need different language and different channels. People say Twitter or Reddit are good channels for devs, and that's broadly true, but think about a Java developer with two kids who has no interest in spending time on Reddit — you can't reach them that way. It might work better to reach someone in their circle, maybe a more junior person on their team who's actively in those communities, and let that person surface your solution to the senior person.
And the third?
This one's very specific to devs: they're building things all day, sitting in front of a computer solving problems they actually have right now, so they're constantly searching for solutions. If you can be present in that flow of searching, that's huge, because they're actually doing it — that's not true of most other audiences to the same degree. There's also an external push: developers want to upskill, partly out of craft pride and partly because they're thinking about the job market and what technologies they should know next. That pushes them to explore new tools even outside an immediate problem.
What's the fourth pillar?
Once you get people interested, get out of the way and let them do their thing. They're builders, so the easiest way for someone to get a feel for your product is to actually try it — a sandbox, a free version, something hands-on — rather than watching someone else demo it, because a demo doesn't prove the tool actually works for them. Usually documentation and code examples are the real 'smell of building' — that's where they see how it's actually solved and how it would look when they code their own situation.
How are you applying those four pillars concretely at Neptune?
Take the first pillar — people are actively searching for things — we're heavy on SEO and blogging, writing for machine learning engineers and data scientists specifically. We're on track to hit 2 million unique blog readers this year, which is significant for a Series A startup competing against much bigger names for that search real estate. We also publish listicles of tools in categories around what we do, so people discover us even while researching alternatives. Second, we're heavy on documentation and try-without-registration examples, plus a free tier so you can actually build with the product before you ever talk to anyone — almost zero investment required just to run the basic quick starts.
You mentioned rejecting the single-CTA convention. What's the thinking there?
A developer told me a few months back: show me the options and let me choose. That felt very devvy to me. The common marketing wisdom is one CTA everywhere, but I don't think that's the best approach for a lot of developers — it's very navigational. They want to see the options and find their own way, whether they have an immediate problem or just want to learn something; they don't want to be told there's exactly one thing they should do right now. I don't think that approach holds, especially with individual-contributor developers.
Are there companies that get this right?
Tailwind CSS's homepage is an amazing example of how to build a homepage for developers — the sheer amount of different buttons and information on it is huge, but it really speaks to what devs need and want. It's definitely not a single button. Algolia is another great example. There are many good ones, but in most cases it's not one clean CTA.
You're closing in on 2 million visitors at Neptune. How do you think about SEO strategy?
I'm not going to give away all the secrets, but I don't think there are that many secrets either. Start with the awareness funnel: unaware, problem aware, solution aware, product aware, most aware. The most-aware search query would be something like 'Neptune pricing' — someone checking for discounts or pricing changes. Product aware means they understand your features. Solution aware is exploring the tools in the space. Problem aware is understanding what problems those tools solve. The strategy is to work down from most-aware, figure out what your audience is actually searching at each stage, and fill in content from the top. There's obviously technical work around internal linking and structuring H2s and H3s properly, but overall it's about having an actual strategy for the keywords you want and the keywords connected to them, not just posting content for its own sake.
Is there an ideal end state for that kind of search-driven discovery?
Some teams manage it — Stripe and Algolia get search results to land directly on docs. That's the holy grail: someone searches for a payment solution for Python and lands on the Python integration page for Stripe. It can't really get better than that. We're not there yet, and it requires the market to be at a certain maturity in terms of how many people are actually searching for those specific things, but that would be the ideal.
As CMO, how do you think about allocating resources across marketing bets?
I think of it like an investment portfolio. There's a core, less risky part of the portfolio with a predictable return, and then riskier bets where you allocate fewer resources but hope for a bigger payoff. When testing a new channel, you try to spend as little as possible to get to an MVP of that channel — there's a great book, Traction by Gabriel Weinberg, that frames this as a bullseye between experimentation and optimization. During experimentation you're testing whether something could work; during optimization you're actually improving a channel that's already working.
How does that investor framing actually play out with your team day to day?
We have a culture of extreme ownership, with some tweaks to the original idea. I like to think of everyone running a project, program, or experiment as the CEO of that channel — as if it's their own small business and I'm an investor deciding where to put resources. As the investor, I want to help, because my money is in it, but I can't run it for anyone — they have to do it themselves. I really like that CEO analogy for how we operate.