
Building a Developer Tools Business - whoisnnamdi
https://manifold.co/blog/founders-guide-developer-tools-sell-to-engineers
======
jasonkester
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,

1.) Developers love to build things.

2.) Developers hate spending money.

3.) Developers undervalue their time.

If your product looks like it would have been fun to build, you'll lose the
entire "insufficiently supervised developer" 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.

I've seen this play out with S3stat customers (which costs $10/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'll break even on your investment in 21
years.

I've had moderate success with my latest API product pointing to a "Boss Page"
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.

It's a tough one.

~~~
bachmeier
This simplified view misses some critical points:

\- The product won't do things exactly the way you want. If you build it
yourself, you get it the way that you wish it had been built.

\- You're investing in someone else's product. Everything you invest in
training and customization is wasted if you have to move to something else.
You no longer have to worry about tech support either.

\- You're locking yourself into someone else's product, and you're stuck if
suddenly there's a big increase in price, the product shuts down (very
common), or changes in some way (even more common).

\- The "developer cost" is tricky. Salespeople like to pretend that you can
calculate that using someone's salary. If you have an $80/hour developer
spending five hours on something like this, you don't literally write a check
for $400. Instead, that developer might have been doing something useful, but
might also have been in a meeting or responding to email or just sitting
around. One argument for 20% time is that the 20% spent on that work wouldn't
have been used productively anyway.

~~~
JamesBarney
> \- The "developer cost" is tricky. Salespeople like to pretend that you can
> calculate that using someone's salary. If you have an $80/hour developer
> spending five hours on something like this, you don't literally write a
> check for $400. Instead, that developer might have been doing something
> useful, but might also have been in a meeting or responding to email or just
> sitting around. One argument for 20% time is that the 20% spent on that work
> wouldn't have been used productively anyway.

This is actually a lower bound on the opportunity cost of having your
developer work on purchasable items.

\- If the dev is making $80/hr they should be adding more value to the
organization than $80/hr.

\- If 20% of your devs are working on purchasable items you'll need to hire
another ~20% to replace them, but then you'll need 20% more managers, QA,
etc..

\- Developer productivity isn't linear, if you hire twice as many devs you
don't get twice as much code written.

~~~
exolymph
> if you hire twice as many devs you don't get twice as much code written.

or if you do, that could be a bad thing ;P

------
sqs
I would also recommend dev tools founders (really any founder) read GitLab’s
company handbook at
[https://about.gitlab.com/handbook/](https://about.gitlab.com/handbook/),
especially the sales and marketing sections. It’s awesome how public they are
about how they operate. You’ll learn a lot.

We (Sourcegraph) have started our own company handbook
([https://about.sourcegraph.com/handbook](https://about.sourcegraph.com/handbook)),
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.

------
FBISurveillance
Call me cynical, but this article looks like one of those ghost-written SEO
articles for self-promotion and improving search result position.

Take a look at DigitalOcean's articles and compare to this one: night and day.

~~~
thomasmarcelis
Sure looks like it. Part one, two and three are written by three different
"Guest authors", who are freelance technical writers.

------
DGCA
I'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't actually know my usage up-front, and that I'm
scared of potentially ending up with a ridiculous bill if I overlook
something.

I totally get that it's on me, but things [like
this]([https://hackernoon.com/how-we-spent-30k-usd-in-firebase-
in-l...](https://hackernoon.com/how-we-spent-30k-usd-in-firebase-in-less-
than-72-hours-307490bd24d)) happen, and I'm way more apprehensive of services
that make that a possibility. E.g. I'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.

~~~
jon-wood
This is something I'm hitting up against a lot at work currently. Our
application is high volume, with a significant proportion of users who don't
bring in any recurring revenue, which makes us very cautious about picking up
new SaaS services which are billed on a per-user basis.

We went through the same process around Auth0, and eventually built our own
solution for handling authentication because even with our current user volume
all Auth0 would tell us on pricing was "contact sales", which tends to be the
case with every product we look at these days.

~~~
enlyth
Auth0 quoted us 25 - 50k a year for 7K MAU, we found this insanely high as we
don't handle any sensitive data.

It seems we might use Amazon Cognito, which seems a bit rough / neglected when
it comes to aws products but the difference is basically free up to 50K MAU.

Couldn't find a nice middle ground, Okta and the others were all prohibitively
expensive as well.

~~~
shantly
If you don't mind sharing, what was it from Auth0's "call us" column for
pricing that bumped you up to that tier? Middle one is still high, but under
$25k, let alone $50k, for 7k MAU.

------
davidjgraph
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't bother with the first part.

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.

It happens in the end user market, sure, but it's easier to find non-technical
first line support to clear out the noise.

------
jangid
This is a promotion of manifold itself. Put it under "Show HN".

------
znq
There also seem to be a 2nd and 3rd part to this blog post.

\- Part 2: [https://manifold.co/blog/founders-guide-developer-tools-
mark...](https://manifold.co/blog/founders-guide-developer-tools-marketing)

\- Part 3: [https://manifold.co/blog/founders-guide-developer-tools-
go-t...](https://manifold.co/blog/founders-guide-developer-tools-go-to-market)

------
golergka
> Docs should be detailed, easy to read, and packed with examples.

But aside from all the examples and tutorials, please don't forget about a
proper manual and full API docs. I'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.

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's not as glamorous as "one button integration" \- but that one button
integration usually turns into nightmare when you want to wire it up to your
automatic builds anyway.

------
imvetri
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.

~~~
pxtail
This is very true, that's what always puts me off when "new exciting idea"
about developers-related tool or service comes to my mind. Additionally
developers themselves are in their own niche so even if at first sight your
brand new product seems to be innovative and non-existing on the market then
it's very likely that it already exists in some form.

~~~
exolymph
SaaS businesses succeed based on the service part, not the software part.

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

------
scarejunba
Here's my opinion without any credentials attached:

* Free tier - essential

* Documentation - essential

* Stack overflow tag - desirable

~~~
nathan_f77
I would love to hear your thoughts about adding a free tier for my PDF filling
service [1]. What's your first impression about the current pricing?

I experimented with a "pay as you go" plan that starts at $0 and includes some
free PDFs, but so far I've earned close $0 from all of these customers. But
this might just be because the people who asked about alternative pricing are
much more price-sensitive and early-stage, while bigger companies don't think
twice about $49/mo.

[1] [http://docspring.com](http://docspring.com)

~~~
felixnavid
I wasn't able to find the free tier plan on your site. Free tier would mean: 2
PDF templates, 100 API requests/month or something similar. All I could find
was a 2 weeks trial. Maybe consider adding a true "pay as you go" tier with a
small amount of money/PDF template and, something perfect for startups and
don't start with a $49 tier.

~~~
nathan_f77
Sorry yes I meant I don't have a free tier now, and have been thinking about
adding one. Thanks for the suggestions! I've also been thinking about adding a
"pay as you go" credit system similar to Twilio, but I'm not 100% sure if it
would be a good business model.

------
ahaferburg
Most importantly, polish the tool.

I'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't like the input. If I come across some cryptic,
ungooglable internal error or access violation or assertion where I'd have to
contact support to even understand what's wrong, I'd rather delete your tool
immediately.

------
laserpistus
A Founders guide to generalising your customers.

«If you want to sell something make features the customer wants to buy and
tell them about it»

------
romanovcode
Does the free-tier/trial really worth it? I've read that from business
perspective those are a waste of time.

------
foreign-inc
There are a few rules:

\- Don'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.

\- Either you or your co-founder is "the" 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).

\- 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.

~~~
corentin88
Could you explain why do you think db or security tools are profitable only?

~~~
faeyanpiraat
The security market is predicted to grow substantially.

This gives space to new entrants.

