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

211–220 of 227 posts

Re: Buy Don't Build

#211

Post by supernovae »

tixocloud wrote: post #119
simonw wrote: post #116

One thing to pay close attention to when making a build v.s. buy decision is the impact that billing models will have on your usage of a tool. Take logging for example. If you buy a log aggregation platform like Splunk Cloud or Loggly the pricing is likely based on the quantity of data you ingest per day. This can set up a weird incentive. If you are already close to the limit of your plan, you'll find that engineers…

Very interesting perspective. Ran into the same issues where Salesforce was charging us by the number of columns we had that ended up forcing the team to overload a column with a JSON object so we could get it to work without overpaying. Integration and maintenance turned out it be a downright nightmare. Would be interested to hear various pricing models to understand the pros/cons for each especially in the logging/…

I hate to break it to ya, but if you do cheats like this when you use reliable off the shelf COTS solutions, imagine the shortcuts they're going to do if/when they try it do this themselves.

Salesforce isn't cheap, but its not exactly expensive either. However, with this short sighted shortcut you did, you certainly cost your company big. That data is useless. If you upgrade, transition, migrate you now have to spend employee time fixing what was a fixed cost.

Human time is expensive. But what is more expensive is putting artificial costs where they don't need to be.

Re: Buy Don't Build

#212

Post by gshulegaard »

pembrook wrote: post #191
gshulegaard wrote: post #135

Earlier quoted context omitted.

I love this comment because it articulates a dynamic that I think is often overlooked much better than I could. I might even go a step farther and suggest that anything that is core to your business flywheel should be built and not bought (in general). Mostly because you don't want pricing to act as a disincentive to exercising the flywheel.

> “anything that is core to your business flywheel” The mechanisms by which your product is marketed, sold and distributed are core to your business flywheel. For example, if you’re a B2B Saas, distribution is often way more important than the product itself. So by the “core to our flywheel” standard you need to build your own email marketing software, your own version of salesforce CRM, your own analytics tool for t…

Hmmm, this is an interesting take, but I think you are expanding the scope of "core to _your_ business" a bit much. Product marketing, sales, and distribution are shared between _all_ businesses so unless you are a marketing, sales, or distribution company I (personally) wouldn't consider them part of the core business flywheel.

For example, let's pretend I have a fictional company that sells a web server. Marketing, sales, and distribution are all important parts of my business, but my "Core" business is the web server software. If I am looking to build reinforcing feedback loops that give me an advantage over time (flywheels) it's my opinion that you shouldn't be looking to build them (at least initially) in marketing, sales, or distribution.

Re: Buy Don't Build

#213

Post by rendall »

nobodyandproud wrote: post #200
disgruntledphd2 wrote: post #188

Earlier quoted context omitted.

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

That’s the problem, isn’t it: Sales is a short-term metric (quarterly?), whereas client retention is long-term (multi-year, depending on contract length). I had the pleasure of carpooling with some random owner of a small tech firm, and he flat out said it was difficult to keep on top of salespersons. Meaning they were pretty shifty by nature and hard to trust.

One of the worst times I had as a developer was when my direct supervisor was a salesperson, who put me on a project that she had sold, and she was also the PM on the project. I thought I was going to die.

Re: Buy Don't Build

#214

Post by papito »

hansvm wrote: post #205
papito wrote: post #43

The most egregious cases of violating this involve trying to create your own CMSs, search engines, and God forbid - databases. There are of course, exceptions. AirTable wrote their OWN database engine, but they knew what they were getting into, and they did it right.

I can't speak to CMS, but are search engines and databases really such a big deal? If postgres or influx or something kinda fits your workload then it's probably not worth the time, but on the other hand I've seen both custom databases and the cludges people have written to work around off-the-shelf DBs, and I vastly prefer the former both in terms of performance and maintainability in a problem space (similarly with…

The problem with search engines is that people think it's just tokenizing the search query and then doing an AND query for the words, but then the fun starts. First of all, there is specific search theory that one has to dive into and have the Knuth tomes nearby. Then, different languages, thesaurus, taxonomies, "did you mean". And we are not even at indexing speed, replication, performance, etc. There is absolutely no chance you would be able to create and maintain a reasonably good search engine part time.

Re: Buy Don't Build

#215

Post by paragraft »

rachelbythebay wrote: post #73

It’s not buy vs. build. It’s _rent_ vs. build. Unless you are actually purchasing whatever it is you’re using... and I’m guessing they aren’t doing that.

Yes, and you only organisationally learn this distinction really once you've been say, bitten hard by a contract renewal that completely up-ends your architecture, requiring huge efforts to stay in compliance with the new terms because by this point you're well and truly locked into the product.

Re: Buy Don't Build

#216

Post by Viliam1234 »

simonw wrote: post #116

One thing to pay close attention to when making a build v.s. buy decision is the impact that billing models will have on your usage of a tool. Take logging for example. If you buy a log aggregation platform like Splunk Cloud or Loggly the pricing is likely based on the quantity of data you ingest per day. This can set up a weird incentive. If you are already close to the limit of your plan, you'll find that engineers…

Once we moved a database to cloud, because we were told it would be cheaper, since we would only pay for the space we actually used.

It also meant that whenever the data size increased, however slightly, the invoice also increased, and managers started investigating whether this increase of data size was truly necessary. Sometimes even when then data size didn't change, managers kept asking whether it could be further decreased.

Making the billing proportional to X means that X will become a political topic. Choose your X carefully!

Re: Buy Don't Build

#217

Post by tixocloud »

supernovae wrote: post #211
tixocloud wrote: post #119

Earlier quoted context omitted.

Very interesting perspective. Ran into the same issues where Salesforce was charging us by the number of columns we had that ended up forcing the team to overload a column with a JSON object so we could get it to work without overpaying. Integration and maintenance turned out it be a downright nightmare. Would be interested to hear various pricing models to understand the pros/cons for each especially in the logging/…

I hate to break it to ya, but if you do cheats like this when you use reliable off the shelf COTS solutions, imagine the shortcuts they're going to do if/when they try it do this themselves. Salesforce isn't cheap, but its not exactly expensive either. However, with this short sighted shortcut you did, you certainly cost your company big. That data is useless. If you upgrade, transition, migrate you now have to spend…

Completely agree. Btw, the abov example wasn’t my company. The CEO just didn’t want to spend. He was also a huge proponent of building everything in-house so we ended up tons of customized software that nobody knew how it ran when people started to leave. The company’s growth eventually stalled and was acquired. Shame because we had some brilliant engineers.

Re: Buy Don't Build

#218

Post by simonw »

Viliam1234 wrote: post #216
simonw wrote: post #116

One thing to pay close attention to when making a build v.s. buy decision is the impact that billing models will have on your usage of a tool. Take logging for example. If you buy a log aggregation platform like Splunk Cloud or Loggly the pricing is likely based on the quantity of data you ingest per day. This can set up a weird incentive. If you are already close to the limit of your plan, you'll find that engineers…

Once we moved a database to cloud, because we were told it would be cheaper, since we would only pay for the space we actually used. It also meant that whenever the data size increased, however slightly, the invoice also increased, and managers started investigating whether this increase of data size was truly necessary. Sometimes even when then data size didn't change, managers kept asking whether it could be furthe…

"Making the billing proportional to X means that X will become a political topic. Choose your X carefully!"

That's such a great way to put it.

Re: Buy Don't Build

#219

Post by watermelon59 »

somuchdata wrote: post #176
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…

I have also seen this from time to time. We have a few engineers in my org and another on my wife's team at another company that have interests similar to yours. I think people with your interests are really valuable. We've changed around what we index on for performance evals/promotions and what work we assign them so that we can better accommodate these sorts of work preferences and skills. If someone is happier wo…

> We've changed around what we index on for performance evals/promotions and what work we assign them so that we can better accommodate these sorts of work preferences and skills.

It's really cool that you've that. And I'm glad to see I'm not alone in this.

Re: Buy Don't Build

#220

Post by lumberjack24 »

Another great read on the topic is from Calm's CTO - https://lethain.com/build-vs-buy

Some interesting takes

1) There's more to it than the 'risk' factor, consider value & costs!

2) Ask yourself "What can I actually build right now?" and be brutally honest before attempting any comparison (vs external tools)

3) Solutions that hinder your efforts to move any component outside their ecosystem are best avoided. These prove to be costly in the long run.

Post reply on HN