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.
- 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.
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 "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.
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.
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 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).
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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?
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.
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).
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…
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.
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.
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.
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.
or if you do, that could be a bad thing ;P
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.
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 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).
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.
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.
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.
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.
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.
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.
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
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.
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.
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?
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.
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".
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).
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…