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