Hacker News Reader

Comment by thinkharderdev | Hacker News Reader

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.

Moreover, it is not quite clear up front whether 1 or 2 will be costlier in terms of development effort and overhead.

View on HN

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 get the same value (unless you have HUGE scale) building it, and should just buy it.

Most organizations aren't comfortable saying "this is all we'll ever need" and are worried about both building, buying, and then migrating, which can be significantly more expensive than either of those options in a vacuum.

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.

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.

Yeah, hosting feature flags in some service is pretty easy (just use ParameterStore!). The hard part is actually using the flags in your application code, which I don't think is something that is easily solved in general

It would seem to me there are still two choices to make, meaning it’s still a binary choice-merely with more caveats and words involved to describe the options?

Yeah, that was phrased somewhat awkwardly. The binary choice I was rejecting was between

1. "Buying" a solution that solves your problem exactly and doesn't require engineering resources to implement and maintain

2. "Building" a solution where you have to solve every problem from scratch where you don't have any particular expertise.

I understand your general point of there being a continuum of paying for building blocks to be integrated. But,

> is not a binary choice

Then, offering two options. :)

Haha, yes that it is a bit awkward

Sometimes though we are dishonest about #1, and we want a deeper level of integration or polish than is necessary.

s/binary/simple/ ... and you're on to something.

cost is often not clear up front, but neither is benefit!

this is where experience matters.

excellent point

This is 100% correct

Reply on news.ycombinator.com