Buy Don't Build
jrott.com
Buy Don't Build
1–10 of 227 posts
Re: Buy Don't Build
#2I agree.
If you are in decision making position, I struggle to see why would you want to spend so much energy installing Prometheus + Grafana stack instead of just using DataDog.
Even worse if your company attempts to build Prometheus/Grafana from scratch. Just why? What a huge waste of money.
If it contributes to your core business then ok, I can see why you may want to build custom solutions.
Re: Buy Don't Build
#3I'm totally on board with the overall message that building (i.e. engineering) your own internal tools come with lots of overhead, but take issue with this one point:
> My counter-argument to that is there is also lock-in with internal systems. The most common version of this is the keeper of the spreadsheet.
The author then disparages spreadsheets as becoming the exclusive domain of one employee who wouldn't want processes to change.
In reality and my experience, though, spreadsheets are one of the most versatile and accessible systems, and their close cousins (Airtable, Notion) great as well! You can customize it to your own processes and they're pretty universally understood, so the barrier to change is pretty low.
Re: Buy Don't Build
#4All of this is true, but sometimes people forget that buying a solution doesn't mean there will be no work. Sometimes, the integration and maintenance of that integration ends up being more than building and maintaining your own solution, especially if you have to do any large changes to how your systems work in order to integrate.
Re: Buy Don't Build
#5Good article, I am definitely filing away to pull out in some future team discussions.
This paragraph is confusing me, either it's missing a 'not' or something, or I'm just confused. Is anyone following?
> The question you should be asking is what else could be done instead of tuning your own stuff or building a new internal system. The answer is usually spending more time coming up with the correct architecture instead of fighting fires or developing actual customer-facing features.
Instead of building internal systems you would be coming up with the correct architecture instead of fighting fires or developing actual customer-facing features? Wait, what? there are too many 'instead of's in there and i'm not sure they are all meant how they are said.
I think developing actual customer-facing features is the goal, but here it sounds like the thing you would like to avoid... and I'm not really sure about fighting fires (ideally you want a system where you do less of that, right?) or coming up with the correct architecture (?).
Re: Buy Don't Build
#6I agree. If you are in decision making position, I struggle to see why would you want to spend so much energy installing Prometheus + Grafana stack instead of just using DataDog. Even worse if your company attempts to build Prometheus/Grafana from scratch. Just why? What a huge waste of money. If it contributes to your core business then ok, I can see why you may want to build custom solutions.
i think there is a huge difference between using prometheus and paying for datadog. the article argues for not building prometheus which makes sense in 99.95% of cases.
btw, the build vs buy should be a topic of discussion whenever people want to build something. at an absolute minimum they need to understand (and use) what’s already out there before they embark on the journey of building themselves
Re: Buy Don't Build
#7I think he's right, if you're at a small/medium sized place, all the reasons he lists there are solid reasons to buy and not build things for yourself. That being said, there's no reason to make that an absolute rule, I think it's ok to build some things and buy some things. Just think of all the things we've ended up with because someplace built some thing and it ended up being some big thing that we all know. Isn't that how Slack and Docker both got started?
Re: Buy Don't Build
#8I'm totally on board with the overall message that building (i.e. engineering) your own internal tools come with lots of overhead, but take issue with this one point: > My counter-argument to that is there is also lock-in with internal systems. The most common version of this is the keeper of the spreadsheet. The author then disparages spreadsheets as becoming the exclusive domain of one employee who wouldn't want pr…
Author here I actually think spreadsheets are great because they are so accessible. What isn’t great though is when there is a business processs that is a spreadsheet and knowledge that exists in one persons head.
Re: Buy Don't Build
#9I'm totally on board with the overall message that building (i.e. engineering) your own internal tools come with lots of overhead, but take issue with this one point: > My counter-argument to that is there is also lock-in with internal systems. The most common version of this is the keeper of the spreadsheet. The author then disparages spreadsheets as becoming the exclusive domain of one employee who wouldn't want pr…
i don’t think it’s the spreadsheet itself. it’s about the process and people who defend the process no matter what
Re: Buy Don't Build
#10I own a Screenshot API service (shameless plug: https://getscreenshot.rasterwise.com/) and this exactly the argument that I make for small utilitarian services like mine. You shouldn't build them because buying them is several orders of magnitude cheaper.
I have a small paragraph from a blog post where I explain this with some math that is probably crappy but captures the idea:
"When you spend time in areas that are not the core of your product, you're actually being financially inefficient. Taking screenshots is likely not a core task of your business so it doesn't makes much sense to waste development resources in this area.
Here is a brief example of how inefficient it gets:
A mid-level developer in a small market earns $90K USD per year, working 40 hours per week. His/her effective hourly rate is $47 USD per hour.
Writing a basic implementation of a screenshot utility will take at least 5 hours. But this is just a simple prototype. Many use cases will need to be addressed, and there's likely going to be a large amount of time spent in optimizing, securing, provisioning, testing, etc.
A realistic utility that can be used for a development workflow is going to take at the very least 30 hours of development time, but likely more.
Other un-accounted areas of development time are: documentation, training and maintenance.
Given this scenario is very likely that writing a semi-good solution will take more than a week and maintaining it, will take at least an hour every month.
This means that writing this solution will cost almost $2000 USD of development time plus another $500 USD or so, just to support it every year. And of course, this doesn't include the cost of the infrastructure you're paying to run it."
My argument is that the more utilitarian the service, the more cost-effective that is to buy it instead of writing it. Writing it could be simple but there's a drain in engineering resources when you try to maintain it in the long run.