Hacker News Reader

Comment by asoneth | Hacker News Reader

In my experience at mid-sized companies the decision is usually made by the development teams themselves who have a choice along a spectrum between a proprietary SAAS solution that may end up costing the company unpredictable amounts of money in the future on one end and a self-hosted open source solution that we have to trust the IT/devops folks to maintain competently on the other.

Also in my experience, the companies that were the most cost sensitive with regard to paying for dev tooling were also the ones with the weakest IT/devops support so you either end up with two good options or two bad options.

View on HN

The cold hard math that engineers never want to do is the one involving their own salary.

On levels.fyi devops is median $150k in the US, and at that price it means they cost the company a lot more including benefits, taxes, etc.

If a "crappy" tool costs $10k/mo for the team and doesn't require much or any devops time to setup and maintain, it's likely cheaper than the $0/mo opensource but requires part or full time management option.

No one ever wants to budget their own cost into the equation!

The same argument applies to the users of the software though, and seeing that played out is even more rare.

If I can run a $0 tool that saves 100 people half an hour a month each because the workflow is better, that's $4k in the "pro" column right there. I should be able to justify spending a day a week on just that one product.

What’s left out is accounting of the time the paid tool wastes. Ten seconds here, a minute there, two seconds another place. If the open source solution is in fact the more productive tool (nb it might not be) then $20,000 in dev time to babysit open source might be cheaper than the $10,000 paid tool—because that tool is wasting more than $10,000 in productivity, it’s just harder to see.

The buyer often doesn't use the product so he has no sense of the value it provides, or the pain of using substandard tools. Unless it's his own company he might not care that much either.

It's not about the cost, it's about the value, unless the products are perfect substitutes, like nuts and bolts. Software products will always differentiate themselves so you can't fairly compare them just on price.

> If a "crappy" tool costs $10k/mo for the team and doesn't require much or any devops time to setup and maintain, it's likely cheaper than the $0/mo opensource but requires part or full time management option.

This is a total fantasy. There is no reason to expect the crappy enterprise tool that costs money will save time relative to the open source tool. In my experience enterprise tools takes more time and average and cost money. This line of reasoning (frequently pushed by dishonest sales people) is seductive because it tricks you into ignore the time cost of dealing with enterprise, not because it is correct.

I think you must be in some terrible giant corporate entity where everything sucks all the time.

I bet you that what I told you about this cost/benefit is being done in every startup that YCombinator funds. I bet you they are all choosing product over staff, because their engineering staff is already their ~largest expense. Their engineers might even cost more than the rest of the company combined including executives.

How many companies are choosing SaaS/PaaS/alltheS so their lean team of engineers can scale to millions, instead of hiring a whole team to manage AWS and docker or whatever ops strategy they have.

You might think it's a total fantasy and in the places you work it may be, but I've been in countless meetings with countless executives where the Google Sheet is busted out featuring engineering cost and tool cost and where cost/benefit is aggressively decided.

Spoiler: it's almost always cheaper to use the tool

> I've been in countless meetings with countless executives where the Google Sheet is busted out featuring engineering cost and tool cost and where cost/benefit is aggressively decided.

That is the problem though. It isn't the engineering cost vs the tool cost. It is the engineering cost vs the tool cost PLUS the engineering cost of dealing with the tool once you buy it. Everything you have said so far leads me to believe you are missing this aspect of the cost of buying the tool.

You are right that there is a time and a place for buying over DIY, but in order to make those decisions reliably you need to know how much effort is going to go into dealing with the tool once you buy it. This isn't something you can figure out using Google sheets, because you have to actually evaluate the tool and get a sense of how dangerous the foot guns are.

You're probably right about scaling though. That sounds like an area where the ROI of paying someone else to do it is pretty good.

Reply on news.ycombinator.com