You launched your dev tool three months ago. You have 40 GitHub stars and a Slack with 12 people in it, and not one of them has said a word. It’s a party where everyone is standing silently by the dip with their coats still on.

How you get devtool users, especially your first 100 developers, shapes everything that comes after. They are your feedback loop and your first proof, and they tell the next 900 whether you’re worth a look. Get them wrong and you’ll spend a year wondering why nobody cares, while the roadmap fills up with features for users who don’t exist.

I’ve spent decades building developer experiences, at Ubuntu, at GitHub, and with the companies Stateshift works with, which is long enough to have made every mistake in this post at least once. Getting those first 100 rests on four pillars: problem, path, proof and presence. Learn them and you stop guessing why nobody shows up and start knowing which part is broken. Fix them in that order and the first 100 becomes a math problem you can work through.

Why do developers ignore a new devtool?

Developers ignore a new devtool when the pitch describes the product and never mentions their problem. Pillar one is problem first.

Most founders lead with the elegant thing they built, like the beautiful API that took six rewrites and a minor breakdown to get right. I’ve admired a clever abstraction long after everyone else left the room, so I say this with love. Developers want the specific, annoying pain they have today solved, the one that made them mutter at their laptop this morning.

Supabase is the example I often refer to. When they launched, they launched as real-time Postgres. That was technically accurate, and almost nobody moved. After months of building, they had about eight hosted databases in production. Most support groups have better turnout.

Then, in May 2020, as they were entering Y Combinator’s summer batch, they changed their tagline to “the open source Firebase alternative” and hit the front page of Hacker News.

The top comment said out loud what everybody was thinking: Firebase had no true competitor, let alone an open source one. Within three days they went from about eight hosted databases to roughly 800. That’s around a 100x jump, and the free tier was being consumed faster than the team could stay on top of it.

They kept the product and the team and changed the problem framing.

Before you touch anything else this week, write down the exact sentence a developer would say out loud to a coworker to describe the problem you solve. Use their words and their problem, and leave your solution out of it. If your homepage doesn’t say that back to them in the first sentence, your positioning is broken, and every dollar of marketing stacked on top of it will leak.

How fast should a developer get to a real result?

A developer should get a real, useful result in under 10 minutes. That’s the path to value, pillar two.

If a developer can’t get a real result on their own code in 10 minutes, with no sales call, no Kubernetes cluster and no API key roulette, the problem sits in your product, and no amount of marketing will fix it. The activation path is the marketing.

Postman calls time to first call the most important metric for a public API, and I agree with them. When API publishers measured it, one company’s developers went from 17 minutes down to 10 minutes by being handed a ready-to-run collection. Another publisher in the study saw improvements of up to 56 times. Packaging the first request so it’s instantly executable collapses the friction. When setup friction and bad docs show up early, trial sign-ups evaporate before developers reach any value. Nobody has ever been delighted by a setup guide that needs its own setup guide.

Stripe hands you test mode API keys and a copy-pasteable curl command, so you see a working charge object come back from the API within minutes of signing up, before you’ve integrated a single line of production code.

Twilio built its early reputation on getting developers up and running in five minutes or less, proven live on stage with founder Jeff Lawson coding a working phone app in front of an audience of thousands. If a developer needs a human in the room before your product works, you’ve got a sales process on your hands.

I’ve seen tools that require a demo call, then a Slack Connect channel, then a network admin sign-off, then a CISO review, all before a developer can see what the product does. Keep going down that road and the next steps are a notarized letter from the developer’s manager, a blood sample, a signed haiku, and a three-month wait while a committee decides whether the haiku scanned.

Instrument every step of your funnel before you drive a single visitor to it. Then design the first touch so a developer can hit a real result before any sign-up gate. If that means a public sandbox, ship the sandbox. If it means a copy-pasteable curl command on the homepage, ship the curl command. This is what we do with clients at Stateshift. The activation path is where many tech companies bleed out, and almost none of them notice until we instrument it and start fixing it.

The order you build all this in matters as much as the work itself. Sequence beats tactics every time.

How do you earn trust before anyone knows your name?

You earn trust by being visibly useful in public before you ask anyone for anything. That’s proof before promotion, pillar three.

A lot of founders skip this because it feels slow. It’s the fastest route there is.

Ship the ugly getting-started guide today, because three rough steps beat a beautiful guide you never publish. This week, answer three Stack Overflow questions in your space and fix one real bug in somebody else’s open source repo. Then write a blog post that solves a specific problem, even if the solution has nothing to do with your product. Yes, really.

Stack Overflow’s 2024 survey of over 65,000 developers found that 82% of them learned to code using online resources, with technical docs the single most used resource. Among the developers learning from docs, 90% reached for the docs that ship with the APIs and SDKs. Your docs are your distribution. Stop treating them as the chore engineering gets to when the sprint is slow, and write them like your commercial life depends on them, because it does.

Tailscale built developer trust by writing long, honest technical blog posts explaining how its networking works, and by owning the awkward trade-offs. That’s this playbook, run in public.

Take the dev tool that launches with a shiny landing page, a three-slide carousel, testimonials from advisors and a webinar that nobody attends. It looks fantastic. It also proves nothing, like a treadmill that mostly serves as a coat rack. A carousel has never helped anybody debug anything.

Where do you find your first developers?

You find your first developers where they already are. That’s pillar four, presence.

Don’t build your own Slack and wait for them to arrive. “If you build it, he will come” made a great movie. It makes a terrible community strategy. The overwhelming majority of a dev tool’s users will never come to your Discord or your Slack. Most company Discords are a vanity project with a moderator.

Show up where they already live, which means the subreddits, the GitHub issues, the Hacker News threads and the Discord servers for the languages and frameworks they already use. Help them there by answering questions without pitching and fixing things before anyone asks. Let them discover you the same way they discover any other engineer they end up respecting, by watching you be useful over time.

Turborepo grew out of Jared Palmer building in public in front of the JavaScript community, sharing progress where they already hung out, long before there was an official channel to join. That audience helped Turborepo gain traction before Vercel acquired it in 2021.

I’ve watched teams spend six months hyping their own Discord to a room of 40 people, three of whom were employees, while a thread on r/devops describing their exact problem sat unanswered for weeks. That’s like hosting a lavish dinner party in your garage while a hungry crowd lines up outside the restaurant next door.

Your own channel comes later, and only if they ask for it. In the meantime, those conversations are already happening, and you can find them and join in without becoming the person who pitches in every thread.

Should you run paid ads to get your first 100 users?

No. Run ads only after you’ve earned your first 100 developers, because paid traffic to a broken activation flow is an expensive way to set money on fire.

I hear two objections more than any others when I talk to companies about this.

The first is, “I’ll just run paid ads and skip all of this nonsense.” Don’t. A broken activation flow will happily swallow every dollar you throw at it and hand you nothing back. Earn the first 100 developers, then and only then scale the channels. That order matters because the best way to convert developers into customers is without selling to them.

The second is, “We hit 5,000 GitHub stars last month, so we’re totally fine.” I wish that were true. A star costs one click and commits nobody to anything, which is why GitHub stars work a lot like Instagram likes for developers. They feel great, and that good feeling is exactly what makes stars the most dangerous number on your dashboard. The numbers worth watching show whether people come back: pull requests submitted, integrations shipped, and developers still showing up on day 7, day 30 and day 90. Without those, 5,000 stars is 5,000 people who looked in the window and kept walking.

Those return signals are the ones worth measuring, because they tell you whether the first 100 are actually sticking. Getting there is the activation stage of how we approach developer go-to-market at Stateshift, and it only works once the problem and the path are right.

What should you do today?

Do two things today: read your homepage’s first sentence out loud, and time how long it takes to get a real result from your own product.

Open your homepage and read that first sentence out loud. If a developer with your exact problem wouldn’t nod and keep reading, rewrite it before you close this tab.

Then time yourself going from your homepage to a real, useful result inside your own product. If it takes longer than 10 minutes, congratulations. You’ve just found your entire roadmap for the next two weeks.

This is a lot of work. I’ve spent my whole career hunting for a shortcut and I’m still empty-handed. Welcome to building for developers. Once you earn them, though, developers are the most loyal audience you’ve got on Earth.

If you want a weekly dose of this sort of thing, we run a free newsletter called SHIFTsignal. One email a week, no fluff, and you can unsubscribe whenever you want.

Common Questions On Getting Devtool Users