I interviewed 100 DevTools founders and this is what I learned

In the last two years, I’ve recorded 100 episodes of Scaling DevTools; a developer tools startup podcast.

These 100 episodes have featured the founders of startups like Supabase, PostHog and WorkOS. And I've also spoken to many more DevTools founders outside the podcast. 

This is what I’ve learned.

The one lesson you cannot ignore: understand your users

I know - so obvious. It took 100 episodes to figure that out?

But, if you're like me, you still don't put enough focus on this. And it maps to the one piece of advice Igor Zalutski from Digger would have given his earlier self:

“Listen. Don't live inside your head. Just listen. It's there. Users are telling you that you're wrong.” - Igor Zalutski, CEO of Digger, Episode 78

So, how do you listen to your users?

Adam Frankl suggests you should create a technical advisory board:

• It should have up to 50 stakeholders
• 30 minute meeting with them once a month (for six months)
• Ask them the following questions:
  1. "If you could wave a magic wand and change anything about how you do [the problem], what would it be? Don't worry about it if it's possible, just anything."
  2. "If I could deliver that, how would that change your life?"
  3. "What change is going on in the world that makes what we just described more valuable than it was 5 years ago?"
  4. Ask about their personal technology discovery loop - where do they learn about new technologies? What conferences do they attend? What blogs do they read? What meetups do they go to?

Doing this helps you understand your users, helps you build a great product and it helps you with marketing and sales.

You just “get it”. And you know where your users hang out and what they read. Even which experts they trust.

When I worked in sales at Stack Overflow, my boss Guy Zerega would repeat daily: "number one rule of sales: know your audience". 

But I’m a developer. I’m scratching my own itch.

It’s good to scratch your own itch but it doesn’t mean you should build without talking to users. 

“If I'm solving a problem that I have, there's this drive to just build it. That's always the number one goal for me - you should be having fun. But also, you don't really know what the thing you're building is until you've seen other people try it and given you feedback. I don't know how many times I've refactored prematurely, and built some beautiful system but then ultimately learned something new from a user and then you need to change a pretty fundamental thing about how your thing works.” - Fred Schott, Astro, Episode 48

You’re making your life harder than it needs to be if you only build for yourself. 

“We build developer tools. We're a bunch of developers. And so we can say: this is what we might like. At a certain point, though, that can actually be a very significant hindrance in building a meaningful developer tool.” - Dennis Pilarinos, Unblocked, Episode 68

Other things I’ve learned from 100 episodes

Product is hard. But growth is harder

This is what I heard emphatically from two of my favorite fellow-Brit DevTools founders, David from ArcJet and Tony from Inngest.

“It's not that building a good product is easy, it's just that engineering founders probably know how to do it. But that's only 50% of building a startup - the other 50% is building the commercial growth engine, and that's much, much harder! As a second time founder, that's what I'm trying to spend most of my time on: how can I get more people to try the product?” - David Mytton, Cofounder of ArcJet

This is also why I started Scaling DevTools and why the sole focus is how you can grow your DevTool. 

“The second-time founder knows they can build products, but they failed because they forgot distribution, or they couldn't get it, couldn't unlock it." - swyx, smol.ai, Episode 33 

If you don’t know how to find your first customers, something went wrong or you are letting fear talk you out of doing what you need to do

I'm guilty of asking this over and over again. I thought I was missing something. But in most cases, I believe it should actually be quite straightforward. And if it's not, you skipped some steps. 

• Do you know where your users hang out?
• Do your users have money/buying power?
• Do you understand what they care a lot about?
• Are you solving the thing they care about?

If you can answer positively on all of the above, the process to find customers should be clear. Although still not easy because it will still require you to get out of your comfort zone. 

“When something works and you've had the experience of knowing the many things that didn't. It's night and day. There's no mistaking it.” - Han Wang, Mintlify, Episode 90

Stripe have written a great guide on getting your first 10 customers but here is what I would do:

1. Research a leads list from LinkedIn.
2. Write tailored messages to each of them via LinkedIn or through email (find their email on Hunter.io etc.). Make sure you focus on their problems and not your solution. 
3. Set up calls with as many of them as you can.
4. On the calls, don’t stress about being smooth - focus on their problem and help them solve it. 

Most importantly, don’t procrastinate by optimizing. Just start reaching out.

Here are some other ideas to find people to speak to:

• Reach out to your friends and friends of friends and ask for introductions to relevant people
• Post content on Reddit and do things like Show Off Saturdays
• Post stuff to Hacker News (see episode with Anh-Tho from Lago)
• Launch on Product Hunt (see episode with Flo Merian)
• Be active on social media and share what you’re doing
• Go to meetups and give talks
• Go to conferences and talk to anyone who’ll listen

If you do still need more resources, I recommend the book Predictable Revenue - we followed it to the letter at my previous startup Code at Uni (coding courses for Business Schools). I wrote about the exact methods we used to generate ~$600k in lifetime revenue.

Is it a knowledge gap or a fear gap?

One more point: if you are still struggling here, ask yourself if you are lacking information or if you are simply avoiding doing the uncomfortable thing. E.g. making a cold email or asking someone to give you money.

Experimentation is the only way

I wish I could say Scaling DevTools has all the answers you need. But it doesn't. It simply has ideas you can try. 

“Be very careful about what you read from traditional marketing. Something that worked for a mid-sized company might not work for you, but it's a good place to start thinking in terms of experimentation.” - Natwar Maheshwari, Director of PLG at Algolia, Episode 5

Even Ant Wilson - cofounder of Supabase - shared that as Supabase has grown, he’s still expecting some marketing gurus to come along and share a magical strategy for more success. But the advice he’s received has been to do more of what is working. For Supabase that means more memes.

The best people know that you try things and then do more of what works.

 “The advice from almost everyone was: you’ve built this engine and have found success. Why would you not double, triple, quadruple the thing that’s working? That was quite nice to hear. So we could go away and throw more fuel on the fire. Make more memes. Double down on talking to developers basically." - Ant Wilson, Supabase, Episode 100

And the thing that works best for you might be something that no one else is doing.

“We realized all these DevTools have marketing departments. But it feels like no one is thinking about it, they're just doing the things you're supposed to be doing. Okay, there's a release: let’s write a blog post. If you think about why you're doing these things, you would never do them, because they don't provide much value.” - Dax, SST, Episode 58

You might need “sales”

There is a common myth that sales doesn’t work in DevTools.

It’s supported by the fact that many DevTools I spoke to - such as PostHog and Supabase - have made very limited investments into sales compared to marketing and product.

Additionally, lots of developers wish salespeople were not effective in DevTools. But that’s wishful thinking. It's easily disproved by looking at jobs pages for some of the biggest developer tools. Would they pay so many salespeople $300k+ a year if they didn’t bring in sales? 

There are many examples of DevTools doing sales.

Vivian, co-founder of the bootstrapped cybersecurity startup Meterian has found sales to be a very effective source of deals.

“In our case, we were using outbound calls to find customers. So we have that list and our sales rep would call them. It works for us.”  - Vivian Dufour, Meterian, Episode 88

Nash Ramdial, Director of marketing at Stream also believes sales becomes increasingly necessary as you grow.

“Sales for DevTools is interesting because, on the surface, it seems counterintuitive; after all, the saying, ‘Developers hate talking to sales’ didn't appear out of nowhere.  This changes as the company begins to scale. If you are going after larger companies, then having an experienced AE or sales team begins to make a difference—especially as they work through complex procurement and legal challenges.”

Shomik Ghosh from Boldstart described it to me like this: if an individual developer can adopt it, you can go bottoms up. But for more complex products it won’t work:

 “If you have a weightier product that requires larger implementation or something like that, that will actually not work bottom stuff. Because an individual developer can't bring that into their organization." - Shomik Ghosh, Boldstart, Episode 36

I even recorded one self-interview where I talked about the time I worked at Stack Overflow in the sales team and did cold emailing. It was hard but it did work. 

Product Led Growth and sales are not mutually exclusive. You shouldn’t rule out sales just because someone told you it doesn’t work in DevTools.

You should be “making content”

Most DevTools I speak to make content. Content has slow, compounding effects for most DevTools. And the long term customer acquisition cost will likely be lower than other channels. 

Plus, as Jason Lengstorf puts it, content is a process not a project. So there are advantages to starting early. 

“The trick to getting to high quality is iterative slow progress. It's a process of trying, learning subtle improvements, trying again, learning again, and continuing that." - Jason Lengstorf, Learn with Jason, episode 34

From my own experiences with Scaling DevTools, you should start early because it's a skill you'll improve at. And good content does disproportionately better than average content.  

Founders and your core engineers should create content

At the startup stage, you should create content internally. 

And it should probably be made by your founders or engineers. Because they deeply understand the problem and the solutions. Your team has interesting, novel things to say on the problem space. And developers will trust other developers way more than dedicated content writers.

“A lot of developers build amazing things, and they think ‘oh, it's okay, it's not that great’. No. You might think it's not that great, but for someone in this world, it's, like, freaking cool. Right?  Put things out there.” - Natwar Maheshwari, Director of PLG at Algolia, Episode 5

So just get your team to write about the interesting ways you are addressing the problems your users care about.

You can also show your users how to solve their problem without you (“rolling their own”). Adam DuVander calls this the Jedi Developer Mind Trick: you show users exactly how to do it themselves. 

“Your biggest competition is a team attempting to build in-house, so it may seem counterintuitive to point a potential customer in that direction. Some readers will go on to build the solution themselves. But many others will realize it’s harder than it looks—and you’ll be the best company to provide a solution.” - Adam DuVander, Every Developer, writing for Heavybit

Share your raw progress and make it visual

In December 2023, tldraw decided to do a marketing week. Lu was given one task: get 100 likes. Lu decided to use OpenAI's vision API with tldraw & share the results. It completely blew up - thousands of likes, millions of views and almost 40,000 new followers on Twitter. According to Lu, why did it work?

Firstly, share the whole process:

“We've realized that the most successful messaging and storytelling is about the journey that we go through and giving people a little glimpse of that. 

I think the most effective way we can do that is to share our shock or surprise. 

Sometimes when you're writing a tweet, you want to show off a bit. You wanna say, hey, look how good we are.

But actually, that's not my genuine reaction when I'm building this stuff. My genuine reaction is, “what the hell”? When something works, and I didn't expect it to work - that seems like a key moment to share.” - Lu Wilson, tldraw, episode 69 

Secondly, when you share content, make it visual.

“Everyone can understand a drawing, not everyone can understand your 16,000 lines of TypeScript" - Lu Wilson, tldraw, episode 69

Visual representations will typically be way more popular and hang around.

Different is better than better 

I learned the value of different from Gonto, who has been run marketing at Vercel and Auth0 and now advises many DevTools startups at Hypergrowth Partners.

One example is how Clerk bought a van, covered it in vinyl and parked it outside YC everyday by Jakob, an engineer in their team (a man destined for great things by the way). 

Another example I saw recently is how Stefan Avram from WunderGraph dressed as an astronaut and handed out pretzels at a conference.

I also got similar advice from Dax Raad that you should be looking for hits. You need to completely stand out.

“On the product side, people know that if your product isn't a hit - if it's just slightly better - you're gonna fail. Average results don't get us off the ground. But that same thing applies on the marketing side as well.” - Dax Raad, SST, Episode 58

And also, if you look at PostHog’s website. It’s completely different. And people talk about it constantly.

Look for inspiration from outside the developer world

Why limit yourself to ideas from the DevTools world? The best creators in the DevTools world - like Aaron Francis - seek inspiration elsewhere. 

“if you're looking for content inspiration, look outside of the DevTools niche. Look at other niches that have had this figured out for a long time. That would include construction, woodworking, furniture making. You take the expertise of people who are just absolutely crushing it, and then you come back to this poor decrepit DevTools space on YouTube, and you're a genius.” - Aaron Francis, Try Hard Studios, Episode 82

Dax also looked outside DevTools for his absolutely hilarious Between Two Nerds series. 

“I spent a day watching every single episode of Between Two Ferns. And I wrote down all the patterns of jokes. And I put in blanks for where it was specific about the person. Then I read all about Fred Schott from Astro and thought about what I knew about Astro and filled it in. And it ended up working out pretty well when I filmed it.” - Dax Raad, SST, Episode 58

Have an opinion

Taking an opinion makes your content much better.

“'Different is better' - people often underestimate that having an opinion can actually be a differentiator. We learned this from our YC partner Nico (Algolia founder).” - Rohan Sood, CEO of Patched

For example, 'Why I chose Vue.js over React is a much better title than ‘Vue vs React’.

Digger had success with a short piece We rewrote our product in Go from scratch. It doesn’t actually have an opinionated title but the content takes an opinion. And it was enough to get them a lot of interested and a feature by ThePrimeagen.

Here's one more example of an epic title from Aaron Francis. It could easily have been something boring like "PHP in 2012 vs 2023". He also got featured by Prime.

Memes do work

This is just an example of first principles thinking. Everyone would tell you memes aren't serious. But Supabase found they were effective so carried on doing them and ignored the naysayers.

“We wouldn’t be sharing memes on the Supabase Twitter if they weren’t so damn effective. People think: I want to sell to enterprise so I need to be serious. But developers who work at large companies of 10,000 people are just like me and you. They grew up on the internet and they think memes are hilarious.” - Ant Wilson, Supabase, Episode 42

Packaging is very important

You can take content to the next level by wrapping up the “nugget” you care about in interesting packaging.

“I think where I have had a lot of success is wrapping a core educational nugget in an interesting, entertaining, hopefully funny, hopefully encouraging package. You're gonna learn how this obscure database thing works. Wrapped around it is personality and excitement and humor. It's like feeding a dog a pill. You cover it in peanut butter, and you're like, hey, do you want some peanut butter? People on YouTube want to be entertained. You have to give them something that is intriguing that piques their curiosity, and then you fulfil that promise in the video.” - Aaron Francis, Try Hard Studios, episode 82 

In the same way with product, Zeno from Resend taught me to focus on packaging and the last few details. Don't just do the thing and push it out. Give your tool the packaging it deserves. A great readme, great docs, great website. And that might take longer than the actual thing. 

“The top 10 launches of that year on GitHub were all for, like, Microsoft, Apple, Google, and then there was just my name on this repo. And a lot of people were asking how I did it. What happened with that specific open source library [clipboard.js] was I spent 2 weeks building before I launched. And 3 days were in the actual source code of the library and the rest was all in the documentation page and on the website." - Zeno Rocha, Resend, Episode 73

Founders should be directly and heavily involved in marketing and community

It’s almost the definition of things that don’t scale but in every good startup I speak to, the founders are doing things that don’t scale.

Whether that’s Michael from WorkOS going to conferences himself to test them.

“I go by myself the first year to scout it. And do a vibe check. Are there people that I think could be customers?” - Michael Grinich, WorkOS, Episode 97

Or a billion dollar-exited founder replying to people on Twitter. Ramiro spoke about the importance of this at Supabase and Auth0:

“I always preach having your founders involved in building community and marketing from the start. You can see that with Ant & Copple from Supabase. Talking with developers, listening to their feedback, answering support tickets, engaging with the community. You see the same with the Auth0 CTO and cofounder Matias Woloski. You could even see it in the last few months. Sadly Auth0 had a downtime and you could see him answering on Twitter to each of the complaints saying, sorry about this. We're working hard on fixing it. I'll keep you updated. And this is a founder with a $6.5bn exit.” - Ramiro Nuñez Dosio, ex Supabase, ex Auth0 

Don’t chase too many growth channels

There’s a danger in trying to do lots of things but doing them badly. 

Especially when you read an article like this saying “make content, do sales, work with influencers”.

But you might only need one or two channels. For instance, my friend Baretto has grown Tiiny.host to $20k+ MRR with just SEO and YouTube. Here’s the interview he did two years ago when they were at $5k MRR. 

This is what Baretto advises on marketing.

“Early stage marketing is like sprinkling seeds all over the internet and then waiting to see what grows. And then doubling down on the single thing that grows. Water it HARD.” - Baretto, Founder of tiny.host

Embrace who you are

You know that saying that dogs end up looking like their owners?

Well I’ve come to the conclusion that DevTools also look like their founders; reflecting their strengths and weaknesses.

Some examples of companies excelling from their founders strengths:

• Alan Shreve - the founder of ngrok - is obsessed with developer experience. So ngrok is world-renowned for great developer experience.
• Ant Wilson - the cofounder of Supabase - is hilarious and so Supabase has the most effective social media strategy of any DevTool I’ve seen.
• Michael Grinich - the founder of WorkOS - is obsessed with WorkOS’s mission of helping companies cross the enterprise chasm - so he has become a thought leader in the space, with popular talks, a podcast and a conference.

But it’s important to remember that while you can be good at many things, you can’t excel at everything. And that’s okay.

You should lean into your obsessions and not be afraid to admit to your weaknesses.

For many weaknesses, you can just ignore them. For instance, don’t try to make hilarious memes if you aren’t funny. Just focus on the other things you are good at instead.

Work with influencers who are experts

Developers are extremely social and influenced by other developers.

“Developers are the most social profession ever. And this comes as a shock. Right? Because most people, you know, they understand the stereotype of the lone developer. Cave dwelling. And every developer has problems. And the first thing they think about when they see a problem is, I'm not the first person to have this problem. Right? I'm gonna search or I'm gonna ask chatgpt, or look in developer social media and see who else has had this problem and how have they attacked it. And every developer has two screens. One screen is the code screen, and the second screen is the answer screen. And you are looking for answers from what other developers have already done to solve this problem. And you're gonna spend more time on the answer screen.” - Adam Frankl, Author of Developer Facing Startup, Episode 98

Because of this, influencer marketing works well. Not in a NordVPN-y/Athletic Greens blanket-sponsorship way though. It’s much better to work with legitimate domain experts. 

Finding the right influencers should be easy if you understand your audience well - ask your users who they admire, whose newsletter they read, whose videos they watch. Then build relationships with those influential people. 

It doesn't even need to be sponsored videos. It can also just be making friends with them or supporting their work where you can. 

And one final point on this. I learned from Sagar to focus on influencers who are truly experts and therefore, influential. 

“The flavor of influencer that is interesting to me is the folks who have done the 10,000 hours and have true taste in the space. The libraries they work on are often open source. They become the key decision makers who push the space forward. They are truly influencing. We all trust their decision implicitly because their work is so core to what we do.” - Sagar Batchu, CEO of Speakeasy (episode coming soon)

As a bonus, these experts will also help you with product feedback.

Don’t micromanage influencers

But one word of warning. You don’t want to tell influencers what to say. Here’s what Nick Parsons, Head of Marketing at Clerk says:

“Give them a sense of direction but leave it at that. Trust them to represent your brand in words that are authentic to them because they know their audience best. As soon as you start forcing influencers to use your words, you lose authenticity. I'm shocked at how many influencers read off a paragraph verbatim from a sponsor. It makes me cringe. Authenticity is the way." - Nick Parsons, Head of Marketing at Clerk

Avoid generic benefits like ‘Ship code faster’

If you find yourself saying generic statements like ‘ship code faster’, ‘built by developers, for developers’ or ‘sign up in one minute’, you probably need to do more work to identify what problems you are really solving.

Here’s Zach Goldie’s process:

“I like to think about the customer and what they're doing, what they've tried already, why it's failed. And then think about the product, what it does, how it’s different. Often, you're not solving the end goal. For example, with monitoring tools, the end problem that you're solving isn't spotting downtime and fixing those issues because they've already got a way of doing that. The problem is that their way of doing that kinda sucks or is expensive or is complicated. The problem is often the way that they're solving the bigger problem. We won't give you 1,000 dashboards that you don't know what to do with.” - Zach Goldie, DevTools copywriter, Episode 60

What have they already tried in order to ship code faster? And why will your solution succeed, while other solutions fail?

You may not need DevRel

In my view, the debate on whether you need DevRel and when you need it comes down to Jobs To Be Done.

• You need technical people who can speak to users and help them solve their problems.
• If you make content, you need people who deeply understand your users' problems and can make content.
• You need technical people who can help close deals. 
• You need technical people who can write documentation.

So, the DevRel debate is secondary. You just need a person (or people) who can do the above jobs.

And for all these jobs to be done well, especially at the beginning of a company’s journey, subject matter expertise is way more important than being great at writing or being good on camera.

So, whether you call them founders, engineers or DevRel - at the earliest stages, bring in people who deeply understand your users, their problems and the solutions you're working on.

I'll give one example: Nolan Di Mare Sullivan from Speakeasy. Nolan's title is DevRel but he's highly technical and has written code for Speakeasy. But has also created content. And acted as a salesperson. Literally everything that's needed. Speakeasy CEO Sagar has told me multiple times how integral Nolan has been.

So DevRel or not DevRel is not the right question. The right question is: can you do the customer facing things you need with your existing team - like documentation, content and conferences etc. 

And if you want to do more of that stuff, who do you need to hire? 

Then hire that person and call them whatever you want.

For example, Clerk does not have DevRel. Instead, Clerk employs highly technical people across the company and encourages them to jump into conversations in the community and talk directly with developers and customers.

You should probably move to San Francisco 🔥🔥🔥

Most of the early adopter buyers are in SF. And that's why Adam Frankl advises you should be in SF.

Plus, the density of DevTools around who can be your friends/customers/mentors is way higher than anywhere else in the world.

And many great DevTools investors I've met like Dana Oshiro, Oana Olteanu, Alana Goyal, Kevin Zhang, Yoko Li, Robby, Alessio Fanelli and Shomik Ghosh are in SF. 

From everything I’ve seen, being in San Francisco gives you the best chance of success in DevTools. Especially if you’re going the VC route.

But you don’t have to move to San Francisco

But you absolutely don't need to be in San Francisco to be successful. Look at Supabase and PostHog. Two of YC's hottest DevTools are completely remote. 

WorkOS and Clerk are also remote but with founders living in San Francisco.

There are also many other exceptional DevTools investors outside SF, such as Megan Reynolds (New York), Ellen Chisa (Massachusetts), Timothy Chen (Seattle) and Alex Mackenzie, Kate Reznykova and Anna Debenham (all London). 

And there are other hubs outside SF - my friend Megan Reynolds is building a huge infrastructure community in New York - which is already the home of companies like DataDog and MongoDB - and will Megan believes New York is the best place in the world for infrastructure.

If you’re not in the US, London is a great place to be. Israel, Paris, Bangalore and Singapore are some of the other places I hear many DevTools coming from. 

“London coding scene is the best coding scene in the world. If you’re in London, visit our office!” - Lu Wilson, tldraw 

If you go big, get funding. Otherwise, bootstrap

In my view, you should only raise VC funding if you're attacking a truly big problem where a multibillion dollar company can be built. Specifically, you should not just  be making it seem like a billion dollar opportunity to investors. You should believe it deeply.

Paul Klein - the founder of Browserbase - is one of the best at this. Because he has a big vision he truly believes in. 

Listen to how Paul talks about Browserbase in their announcement video:

“I started seeing this massive problem and realized this is the company I should have started… We have this head start on building this primitive that every developer is going to need to build the future of software.” - Paul Klein, Browserbase

If you go the VC route, you really need to have the type of big vision Paul has. Otherwise, it's better for everyone to bootstrap. You can always realize the huge vision at a later point though and raise money on better terms - like Fusion Auth did. 

I've met bootstrapped DevTools founders making many millions of dollars. But those millions might not have been enough for an IPO. And if they'd raised VC money, they'd have had a lot of pressure to change the business to meet investor expectations. 

There are also middle ground paths. Check out the episode with Flagsmith about how they partnered with Polychrome (a mini private equity firm for DevTools).

“I met Polychrome, and within 10 minutes I knew this was gonna be the best deal of my life. They had a very, very different model. They gave us a small amount of money and agreed to work themselves on the business until it got to $40k MRR.” - Ben Rometsch, Flagsmith, Episode 83

Maybe I’m overcooking the point but there are bootstrapped DevTools founders out there that you’ve never heard of who are making life changing amounts of money every year. 

So unless your goal is to completely change the world and/or become a billionaire, I’d consider trying to make it without raising.

Understand the chasm you need to cross

This is one of the most theoretical parts I learned. Essentially, your earliest customers will not look like your later customers. They have vastly different needs. “Innovators” and “early adopters” will try you out with just a good product and a vision. This is because they think about the possibility that you will give them an advantage.

But the “majority” are risk averse. They will require you to have case studies, appear on Gartner reports and generally seem very credible. This is because they think only what could go wrong. If they bring your tool in and it goes wrong, will they be fired?

“[To cross the chasm you need to be able to] write documentation and demonstrate use cases that help the less imaginative and less creative or more risk averse people to see the benefit of your technology. Every single dev tool adoption is a choice. Is someone choosing to forego something that is probably more tried and tested in favor of something that is newer, because of some story you sold them or some need that they have that isn't being fulfilled. Whatever that is, helping them understand that what you do to help them should be your primary job.” - swyx, smol.ai, Episode 33 

You need to understand the adoption curve and your stage because it will dictate what you need to provide people before they adopt your product.

There is an enterprise feature chasm

Michael Grinich from WorkOS first put me onto this. Crossing the enterprise feature chasm is related but not the same as crossing the chasm. 

Even if a big enterprise is innovating and happy to try working with a startup, there is still feature work involved in being able to work with enterprises.

Examples of these features could include:

• Single Sign On
• User provisioning/deprovisioning - e.g. being able to log ex-employees out of all services 
• Audit logs

Michael touches on the first interview I did with him and goes into more detail in this talk called Crossing the Enterprise Chasm.

Disclaimer: WorkOS sponsor Scaling DevTools.

There is also a “Team” feature chasm

Max Rozen put me onto this:

“With OnlineOrNot I noticed there's even a team feature chasm. Growth was steady, but I would sell significantly more solo plans than team plans. It wasn't until I completed the team management feature, added on-call integrations and sending alerts to multiple Slack channels that the team plan started selling well.” - Max Rozen from OnlineOrNot

You should have fun

It's a long road and to build a massive company you need to enjoy the ride.

“We asked: what's the difference between someone that builds a $50bn business compared to a $2bn business? And he's like, well, basically, the ones that build the biggest companies like working in them. If you hate your job, you're not gonna get there.” - James Hawkins, PostHog, Episode 85

Hire people who care

Open Source seems to be a bit of a hack here. Hire your contributors. Or hire early adopter customers.

James from PostHog advises hiring people who realize the vacuuming needs doing and do it. Not people who only do it when asked.

You can be successful - open source or not

There are numerous examples of successful developer tools like DataDog, WorkOS and Clerk which aren't open source. 

There are also examples of startups like PostHog which began focusing heavily on being a self-hostable open source tool but now focus more on cloud adoption.

“We have a self hosted open source product, but our focus isn't that [anymore]. It's cloud adoption… because we’ve had so much noise from the repo” - James Hawkins, PostHog, Episode 85 

On the other hand there are benefits to being open source and Ant from Supabase even says “Just do it” because it helps with adoption:

“It's night and day. They launched their initial proprietary version, and then later, they launched the open source version. And the open source version hit the front page of Hacker News. Developers are just more philosophically aligned with the idea of open source than proprietary.” - Ant Wilson, Supabase, Episode 100

I wrote more about the pros and cons of open sourcing here.

Don't waste time on GitHub stars

I get asked to star a lot of repos and I think it’s wasted effort. Why not, instead, ask me about my problems or if I know anyone with a relevant problem? It’s true that stars can be a signal to customers and investors. But if you hit on a real problem, you can get 1,000 GitHub stars overnight from Hacker News. So, in my view, don’t waste time asking for stars. They should be a trailing indicator that you’re doing things right. 

Conclusion

If you take away one thing from this article: talk to your users.

As for me, I’ll continue interviewing DevTools founders, working on DevTools and sharing what I learn. 

If you enjoyed this, please let me know on Twitter or sign up to my newsletter here.

Gratitudes:

• Michael Grinich from WorkOS for being a big supporter and sponsor of Scaling DevTools. Thanks to WorkOS, I can spend so much more time on DevTools. (Also, thanks for taking me flying).
• Elliott Roche, the editor extraordinaire behind Scaling DevTools. 
• All my guests.
• All the Scaling DevTools listeners. Especially Marty from Orbital who even made the Imaginary Jack Bridger Twitter account.
• Lydia and James, who helped me get Scaling DevTools off the ground.
• Adam DuVander for taking a chance and being my first guest and for being so supportive.
• Ant Wilson, Joe Roddy, Nick Parsons, Flo Merian, Utpal Nadiger, Igor Zalutski, George MacRorie, Chris Butcher, Elliot O'Connor, Colin Sidoti, Sahand Seifi, Ramiro, David Miranda, Louis Knight-Webb, Megan Reynolds, Zeno Rocha, Han Wang, Oana Olteanu, Max Rozen, Paul Klein, Jakub Czakon, Eric Allam, Baretto, Brad Simantel, Janaka Abeywardhana, Aditya Rohit, Charlie Ward, Edoardo Lanzini for great advice and support.
• The whole London DevTools crew.
• The Developer Marketing community.
• Adam Frankl for informing a disproportionate amount of my thinking.
• Anne for replying to every one of my newsletters
• Everyone that helped me review this including Nash Ramdial from Stream, Peter Cooper from Cooper Press, Paul Anthony Wiliams from ittybit, Nick Parsons from Clerk, Misato Ehara, Rohan Sood from Patched, Max Rozen from OnlineOrNot, Yoeven D Khemlani from JigsawStack, Flo Merian from Mintlify. You are legends.
• I know I’ve missed people here who have helped me out significantly. Thank you to everyone who has helped me.

Resources to learn more

• Kuba’s amazing Developer Markepear - most comprehensive developer marketing resource
• Heavybit’s resource library - great for enterprise sales content 
• DX.tips - swyx is one of my favorite DevTools people. He writes and curates this amazing resource.
• The Developer Marketing community - my favorite Slack community.
• PostHog’s blog - very entertaining and honest blog with articles such as How we got our first 1,000 users
• Max Rozen’s OnlineOrNot Diaries- an ‘in the trenches’ DevTools newsletter on Max’s journey building OnlineOrNot
• EveryDeveloper - the place I go to when I’m having content challenges e.g. writing a tutorial
• David Cramer’s blog (founder of Sentry) - useful articles such as You Suck at Marketing
• Open Source Startup Podcast - extensive collection of interviews with DevTools founders
• Crossing the Enterprise Chasm - Useful interviews often on DevTools. My favorite is the episode with Gonto.
• Hypergrowth Partner’s blog - Gonto was CMO at Vercel & has written articles such as Why Technical SDRs are the Future of DevTools
• Software Snack Bites from Shomik Ghosh - covers important topics I wouldn’t even think to ask about. Often DevTools.
• Console.dev - very helpful way to discover new DevTools
• DevTools fm - a bit like the technical version of Scaling DevTools.