Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Buy Don't Build

jrott.com

Post reply on HN
Print view View original

181–190 of 227 posts

Re: Buy Don't Build

#181

Post by dmlittle »

cinquemb wrote: post #179
dmlittle wrote: post #178

Earlier quoted context omitted.

I haven't used DD logs personally but from what I've been told if you send the majority of your logs straight to archive to an S3 bucket and only rehydrate the logs when you need to access them their pricing is pretty reasonable. Because you're storing the logs in your S3 bucket you can keep them however long you want and rehydrate them when you need them (say 30 days later). The bill will still be in the low thousan…

You have to survive as company long enough where paying 30k/month sounds reasonable for logging… esp if your revenue is nowhere near it, and are not VC funded… and you will always have to maintain your integrations at the very least.

If you're using log rehydration with DD it's hard to hit the $30k/mo fee. Before I left my last company we were evaluating DD logging and it came out to ~$5-6k/mo for about 25B logs per month.

When you start you'll likely pay a few hundred dollars per month tops. Your personal time alone is probably worth more than that.

Re: Buy Don't Build

#182

Post by doonesbury »

trabant00 wrote: post #180

There are several good comments in here explaining cases and reasons to build instead of buy. But they are all techical and miss one critical thing: human motivation. Nobody cares about your bussiness as much as you. The motivation behind your product/service provider is to take your money. Buying will always be a battle with the other party to get value for your money. They are strongly motivated to offer as little…

Amen to that! Giving a damn is absolutely needed. See longer response elsewhere this comment section.

Re: Buy Don't Build

#183

Post by doonesbury »

taylodl wrote: post #76

Systems of Differentiation should employ a build-first strategy. These are the systems that differentiate you from your competitors, they are your competitive edge. As such you typically need tight control over these systems and don't want to rely on 3rd parties - either vendors or contractors. Systems of Engagement & Systems of Record should employ a buy-first strategy. These are typically more operations-focused sy…

Like the post, and use of definitional concepts. Useful. Thank you.

Re: Buy Don't Build

#184

Post by Mandatum »

watermelon59 wrote: post #165

I hope this doesn't get buried, because there's something that I feel like I'm a bit of a unicorn about. > The problem then with that is everyone who is working on those services is usually trying to get off of them. After all, no one wants to work on something that their boss doesn’t care about. > Yes, your CI/CD system is absolutely critical, but it’s easy for executives to not think about. This leads to a failure…

Seems like your interests align to some SRE and DevOps roles, but you'd definitely need to shop around and it'd only work at large companies.

Re: Buy Don't Build

#185

Post by cinquemb »

dmlittle wrote: post #181
cinquemb wrote: post #179

Earlier quoted context omitted.

You have to survive as company long enough where paying 30k/month sounds reasonable for logging… esp if your revenue is nowhere near it, and are not VC funded… and you will always have to maintain your integrations at the very least.

If you're using log rehydration with DD it's hard to hit the $30k/mo fee. Before I left my last company we were evaluating DD logging and it came out to ~$5-6k/mo for about 25B logs per month. When you start you'll likely pay a few hundred dollars per month tops. Your personal time alone is probably worth more than that.

Before I left my last company, we were spending about a couple hundred dollars per month just on media storage/bandwidth alone for serving academic papers/docs/data (as well as our logs)… in top 5k in alexa, top 100 in indonesia with about maybe 60-70 customers paying 150-200 dollars per year coming from mostly EM countries… the customers can barely afford/justify spending what we were offering over using some open source alternatives, and there would be no way in hell we'd spend that on just logging.

I at least helped 10x the customers and cut costs from when I joined to before I left (stayed a little over a year)… but man, talk about constraints…

Re: Buy Don't Build

#186

Post by doonesbury »

einpoklum wrote: post #99

This is Capitalist logic, and more specifically - an argument for the concentration of capital in the computing/IT sector. We, software developers and users - people and small organizations - should adopt the opposite slogan: Built, Don't Buy. When we build, we improve our knowledge and understanding of systems. We help affect them, through engagement with their developers or through modification and forking. When th…

I like this comment a lot. It's new perspective here. Of course capitalism is great. The US is only 25% of China's population and still we produce well. China copied of lot of capitalism. Silicon valley is hard to replicate in other countries. But we Americans (I'm one at an American company) do have a penchant for confusing R&D and longer term investment distorting it through the lens of a short term bean counting dollar mentality. Usually in the medium to longer term is the loss of customers and market credibility by anemic products of crappy quality. And as far as that goes hasn't this been talked into the ground through the 1990s under the broad topics of SPC and TQM? I could mention pithy quotes from Iacocca, Ishikawa, Deming, Drucker and so on but I wont. To compete world wide usually requires deep knowledge in teams, organizations that lead to client centered services that require mature processes and engineering talent to build. You cannot buy that. That deep knowledge helps demarcate build vs buy.

Let me mention one story here to make the point in the small. During the 80s/90s HP did selectively less OEM work. They bought Fujitsu wave soldering and pick n place machines. That is something like 1million per line. That kind of equipment comes with a serious stack of user manuals. HP threw those out and provided their own set with training. Why? Any fool can plunk down money. Smart OEMs needed a way to get their line engineers to "know how the line thinks" and to move jobs in and out of the line smoothly in an integrated process with attention to spc, quality and metrics tracking. Yes they bought but not by going ignorant.

Re: Buy Don't Build

#187

Post by nine_k »

When you have more money than time, prefer buying. When you have more time than money, prefer rolling your own. It's a well-known principle.

For a VC-backed startup with millions galore and a pressure to beat competition, buying is natural.

For a bootstrapped company or a side project, building your own may be best, especially when the advanced features that make market-leading solutions more expensive does not add a lot of value at the company's current scale, and the growth is not exponential.

Re: Buy Don't Build

#188

Post by disgruntledphd2 »

rendall wrote: post #136
ethbr0 wrote: post #133

Earlier quoted context omitted.

Isn't that a win for everyone except the sales rep though? If the deal closes, Z% of the company ends up being tied up in trying to kludge Y into doing what was sold, spiking engineer burnout and lowering morale, and furthering a negative relationship with sales. Plus you've now pissed off your new customer, by lying to them.

Alas. Then the company doesn't get the contract, while the next company who lied, with a bright white smile, does.

I worked for a FAANG where this was part of my job. I would often come into rooms and question why the client was spending money on a product that didn't appear to suit their needs.

This was incredibly effective, as it meant that the client actually trusted us when we said something would work.

That being said, I'd normally avoid calling our products crap (even when they were) and just push the client to use something that wasn't crap.

This only worked though, because we had a separate reporting line to sales, so any VP pressure had to go through our VP (which happened, but not as often as you'd think).

My understanding is that they changed this after I left, with predictable consequences.

Re: Buy Don't Build

#189

Post by bern4444 »

madrox wrote: post #175

What this doesn't mean, though, is Buy Everything. Buying everything is also how you get poor quality and poor process. It's important to recognize what's core to your culture. It's why I prefer discussing this as a what is core vs commodity decision. If there's a general rule for making these decisions, I haven't found one. What's helped me, though, is asking whether or not the problems my team has is any different…

DSS?

Re: Buy Don't Build

#190

Post by lta »

mlthoughts2018 wrote: post #51

I think all four points in the article are deeply wrong. 1. It is easy to run your own services. You should be investing in internal developer tooling that makes this easy, and in fact that developer tooling should sit in front of any vendor solution you ever buy so that the way it integrates with your alerting, monitoring, data exporting, etc., is completely standardized to be uniform with service delivery in any ot…

Thank you for your answer. I was desperately scrolling in search of one like this to support.

I'm especially angry at the dismissal of the vendor lock-in problem in the main article. I've seen quite a few start-ups being trapped by a vendors which were very cheap at first (trial period, starter plans, etc.) and ended up eating much of the profits. Not to mention the innovation cost...

Post reply on HN