Behind Built for Devs

I've spent nearly 20 years in tech—10 of them in developer relations. Twitter. Snapchat. Lacework. Pantheon. And before all of that, engineering.

That means I've sat on both sides of this problem. I've been the developer hitting a wall with someone else's product and quietly moving on. And I've been the DevRel lead watching adoption numbers flatten with no real explanation for why.

The frustrating part? The tools to actually understand what developers experience have always been either too expensive, too hard to configure, or too limited to tell the whole story. So teams guess. They rewrite docs. They simplify onboarding. They ask their network. And the numbers barely move.

I ran Built for Devs as a DevRel agency—bringing in real developers to try my clients' products and share candid feedback. Those sessions consistently drove the biggest impact of anything I did. Bigger than strategy docs. Bigger than campaigns. Watching a developer hit a wall with a product—in real time—gave teams exactly what they needed: clear, specific insight into what was breaking their developer adoption.

So I pivoted to focus entirely on that. And then I kept asking the next question: what if you didn't have to wait for an evaluation to know something was broken? What if you had that signal continuously?

That's what Built for Devs became.

Every dev tool that figures out why developers are dropping off becomes a better product. And every developer who finds a tool that actually works stops wasting time and keeps building.

That's the loop I'm trying to close.

Dev tools that use Built for Devs get the data, the human insight, and the recommendations to improve their developer experience. The developers who try their products get better, less frustrating tools as a result. And the developers in our evaluation network get paid to do something they'd probably do for free—try new tools and say exactly what they think.

Everyone wins. And that's the point.