Live data from Hacker News

Buy Don't Build

jrott.com

11–20 of 227 posts

Re: Buy Don't Build

#11
post #2

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

> so much energy installing Prometheus + Grafana stack instead of just using DataDog.

Because it could be done in few commands the second time. And learning is only possible when wasting time on this kind of things, rather than trying hard to custom fit your usecase using some buyable tool.

That being said, I kind of partially agree with you and the author though. Don't maintain service just to feel that you are in control, but with the exception that if you are doing it for the learning purpose.

Re: Buy Don't Build

#12
post #3

I'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…

> their close cousins (Airtable, Notion) great as well!

Their close cousins are locked, proprietary, slow, bloated, exceedingly complex, poorly designed (ui/ux), emojized, vc-backed feature extravaganza and have a subscription fee.

Experts of Excel use keyboard exclusively, their keystrokes are a melody of efficiency, expressivity and productivity that is continued to be mocked in similar fashion as the 2007-era Mac vs. PC advertisements.

Re: Buy Don't Build

#13

Good 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 inst…

Yeah developing actual customer facing features is the goal. That paragraph needs to be edited

Re: Buy Don't Build

#14
One of the few things I appreciate from my abusive first boss was making me acutely aware of the value of my own time.

He was incredibly stingy with money and always wanted to know how much it would cost him to have his engineering team implement something vs how much it would cost to buy it and integrate it.

Admittedly he was pathologic about this to the point of having us create a timer that counted in pounds sterling that he'd start running at the start of every meeting, but I feel like it made me way more efficient with my time (and hate long meetings)

Re: Buy Don't Build

#15

I 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…

[deleted]

Re: Buy Don't Build

#16
post #3

I'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…

> their close cousins (Airtable, Notion) great as well! Their close cousins are locked, proprietary, slow, bloated, exceedingly complex, poorly designed (ui/ux), emojized, vc-backed feature extravaganza and have a subscription fee. Experts of Excel use keyboard exclusively, their keystrokes are a melody of efficiency, expressivity and productivity that is continued to be mocked in similar fashion as the 2007-era Mac…

Excel has a subscription fee as well.

Re: Buy Don't Build

#17
post #3

I'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…

> their close cousins (Airtable, Notion) great as well! Their close cousins are locked, proprietary, slow, bloated, exceedingly complex, poorly designed (ui/ux), emojized, vc-backed feature extravaganza and have a subscription fee. Experts of Excel use keyboard exclusively, their keystrokes are a melody of efficiency, expressivity and productivity that is continued to be mocked in similar fashion as the 2007-era Mac…

I found Notion to be fairly simple to get started. Whereas when I opened Airtable my head exploded and I closed it immediately and haven't revisited it since.

Re: Buy Don't Build

#18
post #2

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

On premise Prometheus/Grafana could be lower than 5% TCO compared to DataDog, at least at places I have worked, and I am including employee time. This isn't particulary a discussion about cap ex. vs. op ex. either.

Re: Buy Don't Build

#19
Totally agree.

Some engineers love to say "I can build this over a weekend". But the main cost is almost always on the maintenance side.

I forgot where I saw this number - in the entire lifecycle of a piece of software, (on average) maintenance cost is at least 8x of the initial dev cost.

Yes, buying a solution also costs time (and $$$) to integrate and maintain, e.g., using a 3rd party API - time to write code, time to set up monitoring / alerting, error handling... There are always exceptions, edge cases, special situations...

But in general there are fewer and fewer things that a web company needs to build from scratch. It takes less engineering time to launch a web product than before, thanks to all those out of box solutions, e.g., SaaS, apis...

I like building a software/web business today than 10 years ago :) One-person (or tiny team) web businesses will be very common (I'm running one [1]), and running an API business is not bad because it actually saves customers time & money(vs building one in-house) [2] thus they are willing to pay a small fee (compared with hiring one or more full-time engineers).

[1] https://www.listennotes.com/blog/the-boring-technology-behin...

[2] https://www.listennotes.com/blog/how-i-accidentally-built-a-...

Re: Buy Don't Build

#20
post #16

Earlier quoted context omitted.

> their close cousins (Airtable, Notion) great as well! Their close cousins are locked, proprietary, slow, bloated, exceedingly complex, poorly designed (ui/ux), emojized, vc-backed feature extravaganza and have a subscription fee. Experts of Excel use keyboard exclusively, their keystrokes are a melody of efficiency, expressivity and productivity that is continued to be mocked in similar fashion as the 2007-era Mac…

Excel has a subscription fee as well.

Yeah unfortunately. We still have a 2016 Excel license and will continue to use it.
Post reply on HN