Building a Developer Tools Business

I find that the key thing to overcome when selling to developers is the extreme reluctance to spend money buying something that they can build themselves. You see,<p>1.) Developers love to build things.<p>2.) Developers hate spending money.<p>3.) Developers undervalue their time.<p>If your product looks like it would have been fun to build, you&#x27;ll lose the entire &quot;insufficiently supervised developer&quot; demographic. Those guys will happily spend tens of thousands of dollars of billable hours implementing an in-house version of your thing to avoid the possibility of outgrowing your Free Tier.<p>I&#x27;ve seen this play out with S3stat customers (which costs $10&#x2F;month, or three minutes twenty seconds of fully loaded engineer cost), where somebody will spend a week building an in-house version of the service and standing up a server to run it. Nicely done. You&#x27;ll break even on your investment in 21 years.<p>I&#x27;ve had moderate success with my latest API product pointing to a &quot;Boss Page&quot; that outlines things like build-vs-buy costs, and why you really would be better off paying us for this thing rather than dedicating an in-house guy to building and maintaining it.<p>It&#x27;s a tough one.

I would also recommend dev tools founders (really any founder) read GitLab’s company handbook at <a href="https:&#x2F;&#x2F;about.gitlab.com&#x2F;handbook&#x2F;" rel="nofollow">https:&#x2F;&#x2F;about.gitlab.com&#x2F;handbook&#x2F;</a>, especially the sales and marketing sections. It’s awesome how public they are about how they operate. You’ll learn a lot.<p>We (Sourcegraph) have started our own company handbook (<a href="https:&#x2F;&#x2F;about.sourcegraph.com&#x2F;handbook" rel="nofollow">https:&#x2F;&#x2F;about.sourcegraph.com&#x2F;handbook</a>), inspired by GitLab. So far it has helped new teammates onboard more quickly and (along with other efforts to diligently document internal practices) helped us work efficiently on a growing team spanning many timezones.

Call me cynical, but this article looks like one of those ghost-written SEO articles for self-promotion and improving search result position.<p>Take a look at DigitalOcean&#x27;s articles and compare to this one: night and day.

I&#x27;ve noticed that a lot of paid dev tools are just priced too high or that I run the risk of blowing my budget depending on scale. I wish more paid dev tools were aware that I don&#x27;t actually know my usage up-front, and that I&#x27;m scared of potentially ending up with a ridiculous bill if I overlook something.<p>I totally get that it&#x27;s on me, but things [like this](<a href="https:&#x2F;&#x2F;hackernoon.com&#x2F;how-we-spent-30k-usd-in-firebase-in-less-than-72-hours-307490bd24d" rel="nofollow">https:&#x2F;&#x2F;hackernoon.com&#x2F;how-we-spent-30k-usd-in-firebase-in-l...</a>) happen, and I&#x27;m way more apprehensive of services that make that a possibility. E.g. I&#x27;d love to use Auth0 for everything, but the risk of spending way too much on something I can roll myself is always on my mind.

As someone who first sold to devs and then switched, many years ago, to the largest end user market that we originally served (indirectly), if I did it all again I wouldn&#x27;t bother with the first part.<p>It slightly depends where your price point is, but the issue is there are plenty of good devs and plenty of really bad devs. The bad ones pay you the annual maintenance and transform into help vampires. The problem is the issues are technical and complex and it sucks up developer time supporting them.<p>It happens in the end user market, sure, but it&#x27;s easier to find non-technical first line support to clear out the noise.

This is a promotion of manifold itself. Put it under &quot;Show HN&quot;.

There also seem to be a 2nd and 3rd part to this blog post.<p>- Part 2: <a href="https:&#x2F;&#x2F;manifold.co&#x2F;blog&#x2F;founders-guide-developer-tools-marketing" rel="nofollow">https:&#x2F;&#x2F;manifold.co&#x2F;blog&#x2F;founders-guide-developer-tools-mark...</a><p>- Part 3: <a href="https:&#x2F;&#x2F;manifold.co&#x2F;blog&#x2F;founders-guide-developer-tools-go-to-market" rel="nofollow">https:&#x2F;&#x2F;manifold.co&#x2F;blog&#x2F;founders-guide-developer-tools-go-t...</a>

&gt; Docs should be detailed, easy to read, and packed with examples.<p>But aside from all the examples and tutorials, please don&#x27;t forget about a proper manual and full API docs. I&#x27;ve seen too many different tools and tech that have spent a lot of money on writing up the happy path, but then completely left me on my own when I encountered some weird error code.<p>Just follow the structure of the whole API you have, and make sure that each member, each function argument and each possible return value is documented. It&#x27;s not as glamorous as &quot;one button integration&quot; - but that one button integration usually turns into nightmare when you want to wire it up to your automatic builds anyway.

Developers hate to buy stuffs. thats why they build stuffs. Few weeks your tool is out in market, some outraged developer is going to release a free version.

Or sell by telling how to sell ... Not bad

Here&#x27;s my opinion without any credentials attached:<p>* Free tier - essential<p>* Documentation - essential<p>* Stack overflow tag - desirable

Most importantly, polish the tool.<p>I&#x27;m not going to get my boss to pay for something that is made out of duct tape. If you want to sell something to people who probably know how to build it themselves, you need to impress them with something shiny. While it should work perfectly most of the time, it should also come with helpful error messages when it doesn&#x27;t like the input. If I come across some cryptic, ungooglable internal error or access violation or assertion where I&#x27;d have to contact support to even understand what&#x27;s wrong, I&#x27;d rather delete your tool immediately.

A Founders guide to generalising your customers.<p>«If you want to sell something make features the customer wants to buy and tell them about it»

Does the free-tier&#x2F;trial really worth it? I&#x27;ve read that from business perspective those are a waste of time.

There are a few rules:<p>- Don&#x27;t be a solo founder, no body is going to fund you. Your idea may be crappy, you can pivot. But solo founder is a big no no, unless you are successful founder with a new venture.<p>- Either you or your co-founder is &quot;the&quot; person in your product area or you are able to hire someone who is. Developer tools companies always try to do this to become #1 (at least in twitter).<p>- You probably should make a new database or a security tool if you are in the B2B space. Otherwise you will have a very hard time making money.