Building a Developer Tools Business | Hacker News Reader

Building a Developer Tools Business

manifold.co

293 pointswhoisnnamdi70 comments

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.

Whilst I've seen this, I think it's more about company and leadership culture than software developer preferences.

Our developers are far from profligate but they'll certainly kick and scream at me if we can't spend money on a tool or service that's going to make their jobs easier and allow them to deliver value more quickly.

To be coarsely mercantile about it, I want our teams to invest the vast majority of their time building systems and services we can sell. In turn, they've mostly come from backgrounds where the software they've built is widely used outside of the business they've been employed by, so again that pushes in the direction of doing things that add maximum value for customers, rather than NIH.

Keep in mind your s3stat product costs $10/month _today_. Plenty of developers and teams have been burned by SaaS solutions that either shut down or blindsided users with a 10x or 100x price increase, so they will naturally price your service under the assumption that the costs will skyrocket in the near future.

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.

These are valid if you're the only one using your custom dev tool, but they don't hold up if other devs in your company are using your dev tool. It'll be the same relationship as buying from the external business.

I think I generally agree with this, but that the bigger data point in any "build vs buy" debate is around the expertise/time available on the team vs the scale of the project.

For example, I worked at a 30ish person startup that was a little less than half engineers. Our product had a ton of traffic, and our growth/sales teams had outgrown the small bundle of cheap/free marketing tools we'd cobbled together. But marketing automation is expensive—so a couple engineers spent time trying to build our own version, insisting it was doable and that it would fit our use cases much better because it was built for them.

The reality is they spent two months working on a marketing automation solution that kind of worked, but was missing the robustness of a normal product that had been built by a dedicated team of engineers over years. The other issue was that those engineers now owned their solution—bugs, feature requests, etc. they were essentially running a second product now.

Eventually, for the sake of their time and our productivity, we just bought software. We could have done it months earlier and saved everyone time and frustration.

I realize this post is specifically about dev tools, but I think the logic is more or less transferrable.

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

Far more likely you will prove to have underestimated part of it or overestimated yourself, and will make something less capable and even farther from your personal ideal than the off-the-shelf version. And that's to say nothing of the bugs and maintenance burden. And even if you surmount those obstacles, you'll probably have to make huge sacrifices in functionality or reliability because, unlike the vendors of the off-the-shelf version, you have other things to do as well (or your boss has other things for you to do).

Just to be clear, I'm not necessarily arguing that it's optimal to create your own tools. I will, however, object to claims that creating tools is all about saving money. Having the right tool and having control over your tools is a big deal.

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

> 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

Your argument works at small scales. My company is working with a vendor who quoted us $10mil for an e-commerce solution. Our execs are now toying with the idea of upgrading our existing solution with a few in-house additions, which might total $2-3mil over a few years. When you scale up, sometimes in house is the only option.

Wow I’d love to know what the e-commerce solution is for. And happy to build it for $1m.

You can extend closed source third party system for just $1m? What you will do when authors of system will just say "No" to your proposal to change/fix/revert something in their system, which is essential for your plugin to work?

How it then comes that there is such a high MacBooks-usage rate especially among developers?

IMO developers want fun when they build something and many of them have fun only for very specific tasks i.e. where they think they are good at. So, yes, it is not easy, but points 2. and 3. are partly wrong.

I think another important point is maybe a lot of developers have issues with trust.

Often times it's not about the money on its own. It's just that I don't trust a critical part of my business to a $10 / month service that I'm not 100% convinced will be around for the long run or has an impeccable track record.

For example, I trust Stripe a lot and have no problem basing my business on them but not so much that company I never heard of who is offering a useful service. It might be good, but without concrete proof or dozens or hundreds of success stories then I feel a lot more confident just rolling my own solution because I know it will work in the way I designed it (with or without bugs but if it's buggy, I know where to go to fix it).

> 3.) Developers undervalue their time.

I must admit that this made me pause and contemplate my relationship with time at work.

I think there's a lot of inefficiency, actually, in a lot of orgs, because devs are highly paid but can't (for whatever reason) be permitted much status at all, which includes other employees whose job it is to do data entry & bureaucratic communication and such that doesn't require a developer's direct input (as having such people to delegate tasks to is a major status thing, nevermind whether it'd make a ton of business sense).

This. A thousand times.

We are developers ourself. 4 years ago we built a great tool (a remote logger for mobile apps)[1] internally for ourselves. We had such a huge benefit from it when developing mobile apps, we thought this tool must be very useful to other developers as well. It was a no brainer to turn it into a SaaS product. But we had no clue about how to market it to people.

So we started reading every book on marketing out there (e.g. "Traction") and listened to a tons of product marketing related podcasts (e.g. "Smart Passive Income", "The Art of Product"). We tried many things over a period of 2 years. Nothing worked. After investing 100k€ in development and marketing money plus a lot of our own hours we were almost about to kill it. When suddenly, after the summer break, sales slowly started to ramp up. Without doing anything, but gaining traction on some of our blog posts about technology and development.

Now almost 5 years since inception we have a nice and stable business with 20k€ MRR and constantly growing. We stopped doing any marketing as you'd learn it from the books and focused entirely on creating value for developers through generating content that is also interesting for ourselves. And to be honest, it also makes you feel a lot better, not having to trick people into buying something.

There's probably still a lot we can learn and do better in order to "sell more", but we're quite happy with the current situation (financially) and really appreciate the feedback and praise we get from the developer community valuing our product.

Without wanting to self-promote our product too much, if you're interested in getting more details about our "failed marketing story" we've just published a blog post[2] on Indie Hackers about exactly this.

- 1: https://bugfender.com

- 2: https://bugfender.com/blog/bugfender-growth-from-side-projec...

Did you put any ad spend behind those blog posts, or did traffic come organically?

We tried ads, but that didn't work. Whether developers just block or ignore them, or we didn't figure out the right message, I don't know.

So all of our traffic is now organic.

Those items don't apply universally or only with caveats though.

1. Developers love to build things that they want to or are paid to. If you had to develop every tool you used for work and bootstrap a complete system you would learn a ton, but not get much done on whatever the original task was.

2. Developers hate using up mental space more than they hate spending money. If I subscribe to your subscription only development tool then I have this little ping in the back of my head whenever I use it or whenever I get an email from you. "Hmm, when does this renew? Is it still worth it? What does this do again?" This is the reason I don't like subscription models. If you're constantly changing and breaking things then that's even worse. The big reason I don't buy things besides the above is that I just get tired of having to justify it and possibly expense it or wait for approval so if it's not something I personally want enough to spend my own money on, I won't' buy it.

3. I mean, maybe someone right out of college or someone with no other constraints besides work on their time. But I covet my time and guard it as my most precious resource.

Purchasing is also an expensive operation. Depending on the company, this might taking a few meetings scheduled over the course of multiple weeks. Maybe fill a procurement form. All things the developer hates.

Once that's done, the service has to be integrated with their Single-sign on platform. If they are lucky. Otherwise they will have to use a shared password manager, which is likely an excel sheet in the shared drive.

Or they can develop a quick hack, spin up a few servers on AWS that cost much more per month than the service. But they can do it on their own schedule. That's the big difference once you are setup as an approved vendor in a big organization.

> 2.) Developers hate spending money.

I don't think this one is true at all. In my experience, developers tend to spend far more than most on education, gadgets, health supplements, memberships, and even food than non-devs.

As a digital nomad, I've seen a lot of devs in a lot of places and it's not uncommon to see them spend more on pure consumption than the average person in their home county earns in total!

I think op is saying developers hate spending money on development tools. Free tools beats for pay tools even when the for pay tool is better by an order of magnitude

In addition to the other responses to this post I’ll add the following: I can easily claim a couple days of my time on a side project at work especially if I can show any kind of return for it. But put $10 on the company credit card?! Every month?! No freaking way! The layers of bureaucracy to get approval for such a monumental undertaking are just… Daunting…

As a developer, I would be happy to pay you instead of having to develop and maintain a close cousin of your product for an obscene amount of time investment.

However, I often encounter these roadblocks :

1) The product is not opensource and I can't tweak the 2 line of code I need to make it work with - for example - a different OIDC provider without opening a feature request that will take forever to ship.

2) The product is a SAAS one. Company policies, network security and common sense prohibit me from sending any data to an external provider that is not vetted. Sorry.

3) It's difficult to ship (enterprise) software that would require acquisition of a commercial license from a dependency in order to work as expected. It's doable for a critical piece that you can't replace, but it's really cumbersome when every single piece start asking for a license in order to work. As someone setting up some infrastructure, I don't like to depend on batches of commercial software either because renewals are a pain.

I built a developer tool for a niche as a side project, and it became cash flow positive quickly. I'm shutting it down tho.

All the points you made ring true, making every sale a slog, even if its a relatively low LTV.

Additionally, support was relatively not fun -- mostly "I didn't even attempt to read the docs, and it is your fault".

Developers do this. On the flip side, "product owners" or clients or "stakeholders" or whatever will, not infrequently, propose a little feature that is someone else's entire product.

I always try to point this out when it happens, and advise them to just pay for it, unless they want to create a competing product.

Bonus points for such requests when that feature/other-person's-product is probably more lucrative than the entire actual product they're trying to build. Which does happen, and never fails to be funny.

In a similar vein it usually sounds much more appealing to do ten weeks of fun work, instead of one week of annoying and banal work (fiddling with configuration, writing glue, navigating customer support/pricing). Even if this is an irrational use of resources.

So setting up and using the thing needs to be not just easier than doing it yourself, but significantly easier than doing it yourself.

Really having trouble garnishing interest in a tool I built (deltatrail.io) so naturally I was intrigued with this article. Seems like the "I can build this myself" response is common even though I know many would rather not (even if they could). What I think I'm gathering is that, a solution needs to be immediately useful. My tool which is a "this may help you down the line" (it actually will) but doesn't provide immediate benefit. They say it's easier to sell Advil than Vitamins, right?

I would also recommend dev tools founders (really any founder) read GitLab’s company handbook at 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), 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.

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

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

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

DigitalOcean's SEO articles are also for self-promotion and improving search result position. IIRC they pay some of the volunteer authors in DO credits.

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

Mixpanel was really frustrating in this regard

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.

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.

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.

Bingo. Risk is what keeps me off anything without a cap on billing. If I spend $25/mo on Digital Ocean, that number's not gonna change unless I tell it to. My site may go down, but I won't accidentally run up a five-figure bill on a just-getting-started side project that's not guaranteed to ever generate revenue.

That and having to keep up with a bunch of different bills.

Auth0 has done some dirty pricing changes as well. They dropped pricing for a while then raised it a ton. Basically pinching everyone who started using their service.

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.

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

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

- Part 3: https://manifold.co/blog/founders-guide-developer-tools-go-t...

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

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.

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.

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

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

Here's my opinion without any credentials attached:

* Free tier - essential

* Documentation - essential

* Stack overflow tag - desirable

The feeling when you find your problem asked and answered on StackOverflow.com

Some things, Money can't buy. For everything else there's... :P

How do you feel about a free tier vs a reasonable try before you buy?

Trial period? Hmm, I think they're both equivalent to me. I just want to give the platform a shot before I commit.

Geocod.io has a free tier and we used it at work until we bought the full thing. Google Cloud has a trial and I activated it and then didn't use it so I didn't actually get to try it.

So not quite equivalent, I suppose, since the lock-in is tighter with free tier. You never put anything critical on trial but you do on free tier.

I don't necessarily need a free tier, but I find short trial periods to be unhelpful for something that needs a considerable time investments to truly try. Often I'll end up getting pulled away after starting a trial on something to do some critical bug fixing and other stuff, and then the 14 days are up without my having much of an idea if the product solves my problem.

I much prefer when the trial counts down some other finite resource that I have some control over, rather than wall time. For desktop software, number of days of actual use are a good option, for SaaS that's often difficult to measure sensibly. (Was the app open in a background tab somewhere? Oops, time's up.) So I'm much more likely to give a trial period with a fixed number of events/tickets/jobs/whatever a go.

Google does this by giving you credits that expire in six months. I think that works well.

Co-founder of Geocodio here :) Glad to hear our free tier model worked for you all. Would love to send some swag your way -- send me your address! mhansen (at) geocod (dot) io

Love your stuff, but I'm semi-anonymous here so I don't want to undo that. I do appreciate the offer, though :)

Stack overflow encourages people to create their own questions and answers.

For a new product would you think it odd if there was a load of questions and answers by the company - faqs sort of thing?

It would be a monitored tag so questions would get answered

This wouldn't bother me as a user. I'm just going for questions and answers and if they're pre-asked and answered that's preferable. It's more of whether StackOverflow allows for that use.

I'm pretty sure they do. You can even sponsor a tag.

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

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.

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.

Huh, I'm not in the market so I'm afraid I don't know. Maybe someone else here who needs this will know.

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.

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»

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

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.

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

The security market is predicted to grow substantially.

This gives space to new entrants.

Reply on news.ycombinator.com