
Build versus Buy - sciurus
https://lethain.com/build-vs-buy/
======
jedberg
My preference in these situations is always to start with buy, and then try to
justify build. Unless it's a core competency to your own business, which it
almost always isn't, it makes sense to let someone else do it better.

Their profit margin is usually in their efficiency in doing it better than
you, and at the same time you get the benefit of all the features they add for
other customers.

Oftentimes the decision to build usually came down to the difficulty in
integration of a commercial product, not the cost. In most cases the cost is
set to be competitive against building yourself.

Except in the case of Splunk. Their pricing is ridiculous.

~~~
weinzierl
> _Except in the case of Splunk. Their pricing is ridiculous._

Their pricing is ridiculous and what is even stranger is that with the ELK
stack there is a good and free alternative. Now Splunk is good, no doubt, but
I still wonder how they can be that successful with that pricing.

~~~
sethammons
We ran the largest elastic search cluster on the west coast some number of
years ago. If you are small enough, elastic search can go a long way. Our data
teams and operations folks celebrated the day that that system was turned off.
Elastic search does not even hold a candle to the way we leverage splunk at
our org, but that could be because we are bigger than some and deal with scale
that few others deal with. Splunk costs us a fortune but enables amazing data
analysis. It is easily our most expensive service we pay for and worth it. It
would be great for our bottom line if it were cheaper, but they can charge
what they do because the do it so well.

~~~
aprdm
Can you give us a sense of scale and what issues you faced by elastic?

------
ChefboyOG
This is the core of the whole debate, in my experience:

"When it comes to build versus buy, the frequently repeated but rarely
followed wisdom is good advice: if you're a technology company, vendors
usually generate significant value if they're outside your company's core
competency; within your core competency, they generally slow you down."

Every startup I've ever worked with has had engineers who advocated "build"
for tooling that fell both outside the eng team's workflow and our company's
core competencies.

I think part of it is that things like marketing automation or customer
support software—things that are vital for most teams past a certain
scale—don't seem technically "hard" enough to justify the price-tags,
particularly to engineers who've been isolated from other parts of the
business.

Without fail, every time I've been part of a team building an internal tool
that we/another engineering team won't use, it goes poorly. I've spent way too
long learning about the ins and outs of email deliverability so that I could
fix a bug in a hacky email platform, when we could have just bought a platform
that works.

~~~
Swizec
> I think part of it is that things like marketing automation or customer
> support software, don't seem technically "hard" enough to justify the price-
> tags

As someone who's built far too many of those because "Buying is just too
expensive" ... good god do I never want to do that ever again. Ever. It's so
fucking hard. You _will_ shoot yourself in the foot. You _will_ suffer. And 3
years later you still won't have something half as good as the purpose-built
SaaS.

If you do that and enjoy it, just spin it off into its own product. Who knows,
you might even get more customers with more expensive problems than the
original startup.

~~~
viklove
This only makes sense if you have a significant equity stake in the company
you're working for. For the vast majority of engineers, they really don't care
about the long-term profitability/success of whatever company they're working
for. They just want to get paid, and hopefully grow as a dev in the process.

They'll learn more by building something in-house than by bringing in a saas
and just writing glue for a living. If you want your engineers to make the
decisions a founder would make, give them a significant equity stake.

~~~
Swizec
It depends. Significant stake helps of course and despite that, I'd prefer
solving problems that need solving than spending a bunch of time on problems
that don't :)

There's a balance.

------
teddyh
“If it’s a core business function — do it yourself, no matter what.”

— Joel Spolsky, _In Defense of Not-Invented-Here Syndrome_ :
[https://www.joelonsoftware.com/2001/10/14/in-defense-of-
not-...](https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-invented-
here-syndrome/)

~~~
kstrauser
I've worked at Not-Invented-Here shops and it was annoying that the Powers
That Be didn't want to use a COTS solution. As much fun as it would be to
reinvent DynamoDB, that's not actually going to help our business.

However, even more annoying is working at a Never-Invented-Here organization.
I've been at a place which hired brilliant people, but then didn't let them
innovate on pretty much anything. Write a simple TCP listener in Python to
read a stream of data and then reply to it? That's crazy talk! We need to
write a full Django app and deploy it behind Nginx behind a load balancer so
that we can pretend it's highly available!

Don't get me wrong: the off the shelf approach is _usually_ the right thing,
but sometimes it just adds complication where it didn't need to be. It's
insulting to be told you were hired for your expertise, but then not be
allowed to actually use it.

~~~
Ididntdothis
“Write a simple TCP listener in Python to read a stream of data and then reply
to it? That's crazy talk!”

This has infected my company quite a bit. People get really nervous as soon as
you write something that’s little novel. Writing everything from scratch is
bad but you also need room for people to innovate.

------
Ididntdothis
I think it’s good to buy something if you can use it immediately without much
customization. If you have to do a lot of customization it’s not that clear.
For example we have bought a system that requires extensive customization and
a lot of people are starting to wonder if the total effort of building from
scratch that does wha we need and not more would have been less than the never
ending customizations of a system that can do way more than we need.

There is also the question of brain drain. The IT department in my company has
outsourced a lot of the tech work to the point that there aren’t many people
left who are capable of making informed purchasing decisions. They mostly read
sales presentations, white papers and Gardner reports but they have no ability
to really assess things. This shows in them repeatedly buying expensive
systems that never get really used.

~~~
closeparen
Would these decision makers have produced better outcomes if they were
managing software teams?

~~~
Ididntdothis
I think they would produce better outcomes if they understood or used the the
systems they are buying or at least listened to actual users. I bet
healthcare.gov would have gone better if some high level people had actually
have tried to sign up for themselves.

------
gk1
As someone who helps software vendors overhaul their messaging to attract and
convert buyers, I've noticed the following things about the "build vs buy"
dilemma (or, from the vendor's point of view: the "build vs buy" objection):

\- More senior buyers (CTOs, VPs) are less likely to pit the vendor against a
DIY option. I suspect it's because they've been through too many failed DIY
projects, or they have great clarity on what is and isn't a good use of their
people's time, or they are better at estimating the (usually huge) amount of
effort that would go into DIY.

\- As the OP points out, a company with huge engineering resources is more
likely to consider the DIY option, because, hey, they have all these engineers
that need something to do. So if you're a software vendor and are tired of the
"build vs buy" conversation, stop trying to sell to other software vendors or
VC-backed tech companies.

\- If someone chooses the DIY route, just set a calendar reminder to check in
two months from now. Chances are they'll be underwhelmed with their progress,
and an out-of-the-box solution might sound pretty good by then. (Don't assume
they'd reach out on their own in that scenario--they've probably spoken with
dozens of other vendors since your last conversation, and forgot about you.)

===

Separately, the part about vendor management is gold:

> To get the full value from vendors, you have to invest in managing vendors
> well.

I've spent _so_ much time helping evaluate and implement different vendors
(usually marketing platforms and similar), only to find out three months later
that the software barely gets used.

On the flip side, if you're a software vendor, don't wait until renewal
periods to check in on your customers and make sure they're getting the
maximum value from your product.

------
tensor
I'm surprised "pricing transparency" isn't included here. A vender that
requires you to call a salesperson and do the sort of negotiation on price
that is mentioned here is always going to take advantage of you.

My policy is: no pricing on the website, requirement to call a salesperson to
talk price? No buy. I'm even willing to pay more to a company with transparent
pricing that doesn't require negotiation. It gives me predictability, rather
than have to worry that once they've "locked me in" they're going to jack the
price and crank all the gears.

~~~
cryptonector
If the product fits the bill, giving them a call is no big deal. But they best
be flexible.

------
KaiserPro
Tangent:

We had the same issue with splunk. We were blowing through our licenses like a
champ.

However the thing that managed to reduce our dependency on splunk wasnt ELK or
greylog (they are all poor comparisons to splunk in terms of speed or chopping
and changing data) it was grafana(with cloudwatch and graphite, later
promethius)

What we realised was that the primary way we were consuming splunk was in
graphs. Why spend millions of pounds on generating graphs indirectly, when we
could make them directly, in near real time!

Not Tangent:

I think like platform choice, it depends on your company. The company that I
was with was utterly incompetent, and unable to see a project through to
completion. Therefore if we build a logging system inhouse, we'd get 40% of
the way there and rebuild it. Leaving two incomplete systems.

Migrating to splunk cloud was done to save costs, and it actually worked. Had
we tried to go inhouse, we'd still have expensive local splunk _and_ a shitty
splunk replacement used by two team on a legacy critical system with no dev
hours.

------
lmeyerov
Article felt more like "not buy", not "build vs buy".

I just spent an afternoon helping someone to get us to run on-prem. Phone
calls! Installs! Vendor management! We didn't even setup TLS b/c gov stuff is
complicated! Working with vendor software is so painful!

Except they were originally thinking they'd have to build what we've spent
years not only building, but building as GPU / data / etc. specialists, and
we've already adopted many best practices for stuff like TLS and navigated
other gov systems for them. (It can still be way better, but imagine if you
had _none_ of that stuff, and then had to support it!). Even ignore how we're
special -- GPUs are magical if you use them right -- just that we have basic
stuff built in and with on-going support. That's so key and adds up over the
years. We do it for our graph investigation niche, but same deal for almost
everything.

As software has matured, and I see more and more orgs dealing with the reality
that they're not Google nor Stripe with thousands of the best-paid software
engineers, I'm convinced articles should be explaining from the default of
"not build".

~~~
mumblemumble
In my less charitable moods, I'm inclined to say that you're unlikely to find
a whole lot of software developers saying you should build less software for
the same reason I've never met a real estate agent who's really on board with
my desire to stick to a more modest living situation.

Besides, building in house is inherently more fun. What would you rather do,
write new software, or pore over manuals for software that someone else wrote?
For my part, there's a reason I became a programmer and not a tech writer.

~~~
lmeyerov
Yep! I find that working with management involves planning through outcomes
and general resourcing, while working with developers and engineering managers
involves planning through the cooler stuff they get to do. ("Instead of
reimplmenting some JavaScript UI and Python backend thing for the nth+1 time,
we'll zip ahead to the GPU era and focus more time on the data engineering and
data science and visual analytics side...")

Folks don't get recognized as heroes for not doing anything, but when they
drive the greater story, everyone wins. Understanding the individuals involved
in successful software delivery is so important!

------
trimbo
I'm super surprised to see this article not mention the phrase "opportunity
cost".

That's what someone pays to save with something like Splunk. Pay cash to make
SWEs more effective towards solving the problems that make up the business's
value prop. Cash is much easier to get than the opportunity to grow the
business with the people already there. That time never comes back.

------
rachelbythebay
Is it really buy? Or is it "rent"?

I'm guessing for most people, it's actually "rent".

~~~
kavalg
My assumption when reading it was that buy means both rent and purchase
licenses/hardware.

------
zmmmmm
To me the primary thing that matters is how strategic the software is to your
core business. This may sound like just evaluating whether it's your core
business or not, but it's a nuance on that which is important.

It's easiest described by an example: we use open source Gitlab extensively.
Numerous times it has been proposed that we migrate to $expensive alternative
because they all have advanced functionality that we don't get from Gitlab (in
many cases, even the enterprise version). Yet we are sticking with Gitlab, and
making extensive customisations (mostly using the API) and workflows adapted
to it.

Is our core business developing software for CI/CD/Issue tracking/source code
management? Absolutely not. But is that _critical to us_? Absolutely. Because
Gitlab is open source and because it has an extensive API, we can eek out
efficiencies all over the place that aren't possible with closed source
software.

So I think it's really important that people use the right frame of mind when
evaluating "core business" or not. You don't have to be in the business of a
selling particular type of software for it to be worth doing "in-house". You
_do_ have to be _good at it_ though.

------
ensignavenger
When you are looking at paying for an expiring license or SaaS product, it is
build versus Rent. And one cost of renting a product is that your vendor's
business may change. Perhaps they get bought by Apple and the product is shut
down, or maybe they just decide to go in a different direction. Or they raise
their prices. Or the service isn't as good as you thought it was going to be.
If you have done a lot of integration work (either in software or
organizationally) you are either locked in or all that work is wasted.

This is addressed in the article as "risk".

The best way to balance this is to prefer buying/renting Open Source software.
That way, if your vendor changes direction, or their service level drops
unacceptably, you can choose a new vendor without losing your integrations. Or
even switch to a self-supported model.

And any improvements you need, you can contribute to the project so that
others can take advantage of them and share the maintenance burden.

------
hauschildt
Nice article. I had published my thoughts from a CTOs perspectives on this
topic a while ago. Maybe it’s a good addition to your article for anyone:

[https://blog.photoeditorsdk.com/build-or-
buy-f09785ce1138](https://blog.photoeditorsdk.com/build-or-buy-f09785ce1138)

------
jbjohns
Personally, I (as a software engineer who loves to write software) would
advocate buy anywhere and everywhere you can. Even your core business. In my
personal experience it's rarely code that's giving you an advantage, it's more
likely to be your data, your connections, your efficiency, etc.

Also, try to use the product as off-the-shelf as possible. Little or no
customisation. If people in your business are unable to work with a product
without customisation consider firing them and replacing them with people who
can before you get involved in customisations.

For me the dominating factor here is human resource pool. For whatever we
build there are no experts on the system except the ones who already work for
us. So aside from all the build, maintenance, etc. costs associated with
build, I also can't find any employees on the market who are experts or even
competent in the software.

------
rconti
One thing overlooked here (or not explicitly called out) is talent pool. My
last boss didn't want to use anything that he couldn't plug into Dice Or
Similar and get dozens of hits for.

If it's not part of your core business/core competency, and you're just
reinventing the wheel so you don't have to pay a vendor, you have to weigh
against the cost of the off-the-shelf solution NOT just the cost of developing
it yourself, but developing it, maintaining it, documenting it, replacing your
"irreplaceable engineer" when s/he quits, etc.

------
nunez
The debate as old as tech.

Sometimes, you don’t get a choice. In most large enterprises, it is almost a
given that you’re going to buy instead of build, and that thing you bought
better come with enterprise support.

------
tschellenbach
I think it's all about focus. There is a limit to how many goals/projects you
can focus on at once. Every new thing you build distracts your focus. You
should minimize what you build in-house to just the things that make you
unique. I like Unsplash' blogpost about this:
[https://medium.com/unsplash/scaling-unsplash-with-a-small-
te...](https://medium.com/unsplash/scaling-unsplash-with-a-small-team-
fbdd55571906)

------
tschellenbach
One thing that's commonly overlooked is the risk/vendor lock in associated
with building things in-house. Sure external vendors sometimes raise prices or
shutdown their product. Those events are pretty rare though and you can
typically move to a competing solution. The real risk is building in-house and
having the people that create the in-house solution leaving.

~~~
TAForObvReasons
> raise prices

Many SaaS have 10x'd their prices over the last few years and it is a
significant risk for any tool that you are "renting".

------
kavalg
I guess the real question is how to correctly distinguish between a commodity
vs a potential lock-in. For example, if you stick EC, S3 and SES, it feels
more like a commodity. However, with more services in the basket you will
probably end up in a lock-in situation and your company will hardly survive if
e.g. your AWS account gets suspended.

------
taytus
You have an idea, you think it is a good idea based on your early validation.

You start the basic design of how it should work, maybe even based on that
early feedback.

If you have no money, and you can build stuff, it doesn't matter if buying is
the best advice.

Should you build or should you buy?

Neither. You should survive.

------
softfalcon
"A company that does this extraordinarily well is Amazon, who issue their
vendors quarterly report cards grading their performance against the contract
and expectations. Getting great results from vendors requires managing them.
If you neglect them and get bad results, that's on you."

\- Gives JIRA a report card on them as a vendor to your business.

\- Is largely ignored because my business is not Amazon scale with all the
power that holds.

tldr; this only really works if you're one of the whales for a vendor.

------
ggm
When your core existence depends on being the only people able to do a thing,
being able to do it with off-the-shelf product begs questions which go to the
axium of you being the only people able to do it.

If you understand the role, this doesn't have to be a problem. Hence
registry/registrar/delegate separation: the registry is not the delegate. the
registrar is not the delegate, and has to meet the demands of systems
boundaries implemented by the registry. The delegate has no software
limitation and no need to own software because its a role divorced from
software. Anything can be out or in source.

Or the CA/RA functional divide in a PKI. Better not to be an amateur
implementing crypto, buy off the shelf because your role is to adjudicate what
happens, not write systems.

------
davidy123
Build, buy, and engage if it's part of a larger project that involves any
innovation. Engagement falls under "vendor management," but that seems like a
very reduced description.

------
DrNuke
You are fundamentally buying your time, so buy as much as you can and stay
focused on your own business?

