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

141–150 of 227 posts

Re: Buy Don't Build

#141

Post by Aeolun »

Raidion wrote: post #87
thinkharderdev wrote: post #25

These sorts of discussion always seem somewhat confused to me because "buying" vs "building" is not a binary choice. It is more often a choice between: 1. Buy some platform/framework which you will then need to hire a small army of costly consultants to integrate and customize for your particular business need. Or 2. "Build" your own solution by orchestrating a bunch of open source technologies to solve your problem.…

I think it's a matter of unknown future needs that's the problem. If you want to do feature flags, you can basically build a service that stores key value pairs segemented however you please, throw it behind redis cache, and call it a day. This is faster and probably cheaper than buying a SaaS! However, if you want a bunch of neat features, custom rollouts, and all that stuff, you're simply not going to be able to ge…

In my experience, integrating a thing like feature flags is a major pain if you do not have control over the implementation. It ends up being kludges and suboptimal choices everywhere.

Re: Buy Don't Build

#143

Post by jtsiskin »

coward8675309 wrote: post #61

The way I put this to clients is that you should own the bricks that your product is made of and not worry so much about the mortar. The bricks are the SQL queries, the logic inside the container images you run, the data stored in the tables and storage buckets. Oh yes, and the business relationships and brand equity. As long as you're wiring those things together in ways you can replicate across cloud providers or i…

I thought one of the main advantages of “running your own (Kubernetes cluster|database instance|pubsub system)” was for exactly that reason - so that “you can replicate across cloud providers or in your own datacenter or on your own server in the closet”.

Re: Buy Don't Build

#144

Post by fuzzythinker »

Raidion wrote: post #87
thinkharderdev wrote: post #25

These sorts of discussion always seem somewhat confused to me because "buying" vs "building" is not a binary choice. It is more often a choice between: 1. Buy some platform/framework which you will then need to hire a small army of costly consultants to integrate and customize for your particular business need. Or 2. "Build" your own solution by orchestrating a bunch of open source technologies to solve your problem.…

I think it's a matter of unknown future needs that's the problem. If you want to do feature flags, you can basically build a service that stores key value pairs segemented however you please, throw it behind redis cache, and call it a day. This is faster and probably cheaper than buying a SaaS! However, if you want a bunch of neat features, custom rollouts, and all that stuff, you're simply not going to be able to ge…

Agree with @Aeolun's comment. Feature Flagging is one exception in buy vs. build where there just isn't any good SaaS out there that makes it "just buy it" worth it. More so if you need customizations beyond what is offered.

Re: Buy Don't Build

#145

Post by XCSme »

I think the answer is somewhere in-between. I really like the idea of "paid open-source", where someone creates a software product and you pay a small license fee to self-host it. This way you still have full control over the software, very low costs but the product is still externally maintained so you don't have to worry about it breaking. The only thing you have to maintain are the servers, but with all the VPS and managed cloud platforms out there, running a server, backing it up or monitoring it is done in a few clicks.

The biggest selling points of such a distribution system should be:

1) It's REALLY easy to set-up, no technical knowledge required.

2) It doesn't require any type of maintenance (eg. can run perfectly at least one year without changing anything, this means that the software should allow for OTA updates).

3) It is a lot (10x) cheaper than a SaaS alternative.

Re: Buy Don't Build

#146

Post by pseudalopex »

gshulegaard wrote: post #135
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…

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.

Then time is the disincentive.

Re: Buy Don't Build

#147

Post by jokethrowaway »

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…

Memories of developers not logging stuff on datadog not to go over limit.

We ended up running our own ELK stack and it was much better.

Re: Buy Don't Build

#148

Post by jokethrowaway »

This implies that employees actually have more valuable stuff to work on or that the leadership in the company know what's valuable, which is not always the case.

Given the limited number of projects creating values, it's often a choice of working on the next failed project or saving the company 100 grand.

Re: Buy Don't Build

#149

Post by coward8675309 »

jtsiskin wrote: post #143
coward8675309 wrote: post #61

The way I put this to clients is that you should own the bricks that your product is made of and not worry so much about the mortar. The bricks are the SQL queries, the logic inside the container images you run, the data stored in the tables and storage buckets. Oh yes, and the business relationships and brand equity. As long as you're wiring those things together in ways you can replicate across cloud providers or i…

I thought one of the main advantages of “running your own (Kubernetes cluster|database instance|pubsub system)” was for exactly that reason - so that “you can replicate across cloud providers or in your own datacenter or on your own server in the closet”.

I don't pack a desk in my messenger bag: a laptop, pencil, and notebook suffice.

Re: Buy Don't Build

#150

Post by zomglings »

ethbr0 wrote: post #127
corytheboyd wrote: post #124

Earlier quoted context omitted.

I have been in the boat of the company that ripped you off before. Sales will promise the world, product/engineering caves “just one last time” to help win the deal with the easiest shittiest thing. Years go by and things inexplicably break all the time. It’s such an easy trap to fall into, because I hear similar stories all the time. I guess the moral of the story is to assume sales is lying to you until proven othe…

Why don't more companies mandate that their engineers talk to the company's engineers, alone, in an unrecorded room, before agreeing to buy? I mean... talking to people with every incentive in the world to stretch the truth and/or little technical acumen doesn't sound like a recipe for success.

There's negative incentive for the selling company to do this. Too much of a risk that your prospective customer's engineers are just there for inspiration.

This is why pilots exist.

Post reply on HN