Four tips for early stage DevTools
After roughly 120 interviews, Jack pulls out the four lessons that have stuck with him most — including one from Zeno Rocha, who spent only three of his fourteen days building clipboard.js on the actual source code, and the rest on the README.
This is a solo essay episode, written for early-stage founders like Jack, who is building his own dev tool, Layer Code. He pulls together four lessons from guests across the show's run: Adam Frankl, Ant Wilson, Zeno Rocha, and Gonto.
Each lesson comes with a short clip from the original interview, plus Jack's own reflection on applying it — including an honest admission about his own reluctance to do the uncomfortable parts of go-to-market.
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.
Lesson one: understand the problem deeply, from Adam Frankl
By far the most important thing, and the easiest to get wrong — Jack has gotten it wrong himself and sees friends get it wrong constantly — is really understanding the problem you're solving by spending a lot of time talking to people who have it. Adam Frankl's take: the biggest reason developer-facing startups fail is that they're not listening to developers. That sounds obvious, but the hard part is that if you're a developer who founded a startup to solve a developer problem, your natural instinct is to write code, put it out, watch people use it, and write more code — and nowhere in that loop are you actually talking to developers. It has to happen deliberately. Frankl's system for this is what he calls a Technical Advisory Board — not technical, doesn't give advice, and isn't a board, despite the name. It starts with the problem, not the product: you talk to as many developers as possible about the problem itself, not your solution, because as a founder your mind is full of how your solution works, but that's not what developers want to talk about. Most developers are eager to talk about their problems — genuinely eager, because no one else in their life cares: not their partner, their boss, or their kids. Get them on a call as a startup founder who cares about their problem, and they won't shut up. It's the founder's job to find these developers and ask, since it's not the developers' job to reach out.
Lesson two: experiment with channels rather than trusting conventional wisdom, from Ant Wilson
Ant Wilson, founder of Supabase, argues you have to try every channel and every strategy to know what actually works for you — you can't just follow a timeless dev-tool rule from a book. Before Supabase, Wilson's team weren't Twitter users and didn't understand the platform, but they tried it and found it worked, then iterated on the blend: a bit of memes, a bit of developer-centric questions, a bit of direct product pushing. They tested Reddit strategies per subreddit, and tried Instagram, TikTok, and in-person meetups, discovering the efficiency of each channel by actually running the experiment rather than assuming. Jack connects this to fear: a lot of what blocks founders isn't not knowing what to do, but being afraid or uncomfortable posting on Reddit or making memes and putting them out there. He gives the example of a friend, Sahand, running Notification API, who loves coding so much that neither he nor his cofounder does the uncomfortable go-to-market work — a conversation that ended with Sahand admitting he just needs to spend the time on the stuff he doesn't want to do.
Lesson three: obsess over the last mile — packaging and presentation — from Zeno Rocha
Zeno Rocha's clipboard.js has around 30,000 GitHub stars, with the first 10,000 arriving within a week or two of launch in 2015 — the same year as React, on a top-ten GitHub launch list otherwise dominated by Microsoft, Apple, and Google. People kept asking how he got that much attention so fast. His answer: he spent two weeks building it before launch, and only about three of those days were spent on the actual source code — the rest went into the documentation page and the website. He wanted a genuinely great README and a genuinely great homepage, with a clear flow, an impactful tagline, and an intro that explained the why before anything else, followed by a demo that felt immediately familiar. Rocha's view is that most developers spend nearly all their time on source code and almost none thinking about how they'll distribute, market, and teach people to use it — when the split should be closer to 50/50, or even 80% toward packaging, given how insanely important standing out has become. Pushing to GitHub is something anyone can do; writing a README that flows well enough that someone wants to share it with friends and use it on a Saturday afternoon side project is what most people miss.
Lesson four: be different, not better, from Gonto
Gonto, VP of marketing at Auth0, argues it's better to be different than to be better — if you do the same thing as everyone else, just slightly improved, nobody notices; if you do something scrappy, colorful, and genuinely different, people notice and it makes a real difference. He's skeptical of the common claim that data is the most important thing in growth and marketing — data helps you iterate and improve, but it doesn't give you creative ideas or tell you where to focus; that requires taste, gut feeling, and creativity, informed by qualitative research that surfaces specific details rather than just numbers. His examples: Clerk bought a van, wrapped it in branding, and parks it outside every San Francisco meetup, sometimes baking cookies so people can smell it — something that doesn't scale but is memorable. GitLab noticed the food at a GitHub Universe event was bad, rented the best taco truck in town, slapped some scrappy stickers on it, and told attendees where to find real tacos — people left wearing GitLab caps and carrying GitLab napkins. Jack's takeaway is that it's not just about being different for its own sake — it's about genuinely understanding the problem and your users first, having taste, and then showing up differently and consistently in the places they already are.
What's Jack's own summary and reflection on all four?
Spend an insane amount of time talking to users and genuinely understanding the problem — become obsessed with it. When it comes to marketing, try loads of different things rather than trusting a book or even this podcast, and see what actually works for your specific case. Spend a ridiculous amount of time on the last mile — the packaging, following Zeno's example — and be different, following Gonto's advice, rather than just doing what everyone else does. And the one lesson none of the guests said explicitly, but that Jack can say for himself: every time he's done the thing he didn't want to do — posting on Reddit, writing an article — it's helped. Streampart, the dev tool he was working on at the time, was very early stage with only a small number of paying customers, but the moments that actually worked were when he swallowed the uncomfortable feeling, put something out there, and put real time into packaging and distribution.