Build vs Buy: How to Think About the Real Decision

The problem

Very few technical discussions go downhill as fast as build vs buy.

That is because the conversation usually slips into one of two extremes.

One side says:

• “let’s build it, because nobody understands our problem like we do”
• “we cannot depend on a vendor”
• “buying is expensive duct tape”

The other side says:

• “let’s buy it and stop reinventing the wheel”
• “this is not core”
• “engineering just wants to build internal products for fun”

Both sides can be partly right.

And both can be badly wrong in the real context.

Mental model

Think about it this way:

build vs buy is not about preference. It is about which option solves the right problem with the most acceptable total cost for this moment.

That sentence helps because it forces the discussion to look beyond the initial price tag.

You start comparing:

• time to capture value
• team capacity
• maintenance cost
• future dependency
• real flexibility
• operational risk

That already makes the conversation much better.

Breaking the problem down

The first question is not “build or buy?”

It is:

“what exact problem are we trying to solve, and what needs to be protected here?”

Without that, the discussion turns into abstraction.

Because build vs buy for authentication, analytics, billing, search, or feature flags are very different decisions.

What needs to be protected might be:

• launch speed
• deep customization
• operational cost
• compliance
• reliability
• team focus

If that is not clear, the decision stays loose.

Buying feels fast until the hidden bill shows up

A lot of purchased solutions look good because they solve an immediate headache.

Sometimes they really do.

But buying also comes with costs that show up later:

• annoying integration work
• customization limits
• pricing that grows with usage
• lock-in
• roadmap changes you do not control
• workarounds around the product you bought

If you ignore that, the math stays too short.

Building feels like control until maintenance arrives

The other side has the same blind spot.

Building internally feels attractive because it gives a sense of control.

But that control costs:

• team time
• focus drift
• ongoing operations
• requirement evolution
• internal support
• debt that becomes a hidden product

Sometimes “let’s build it” really means:

“let’s take on one more product and not say it out loud.”

That is a good question to bring into the conversation.

Core business helps, but it does not solve the decision alone

People often use this phrase as a shortcut:

“this is not core, so buy”

or

“this is core, so build”

That is still too shallow by itself.

Because even something that is not core might require:

• critical customization
• high regulatory risk
• important differentiation in the experience

And something core might not deserve a full build from scratch at that stage.

Better than asking “is it core?” is asking:

• how much of this do we really need to own?
• how much control does it require?
• how much cost makes sense to carry now?

The company stage changes the answer a lot

This is a decisive point.

A small startup might buy because it needs to learn quickly.

A larger company might build because the vendor cost became too high.

A team with weak operational maturity might buy to avoid creating another critical system.

A team that needs strong customization might build because the vendor becomes a ceiling.

The same decision changes a lot with the stage.

The best answer usually accepts a hybrid model

In many cases, the mature decision is not 100 percent build or 100 percent buy.

It can be:

• buy now and replace later
• buy the base and build the differentiating layer
• build only the part that really needs control
• avoid a full internal product and integrate more deeply instead

That answer usually sounds more grounded.

Because good teams rarely treat the choice as absolute dogma.

Simple example

Imagine the decision to add recurring billing in a SaaS product.

Weak answer:

“I would buy it, because billing is not core.”

Or:

“I would build it, because depending on a third party is risky.”

Both answers are shallow.

Better answer:

“My first question would be what is at stake right now. If the priority is to enter the market quickly and the team does not yet have the capacity to operate billing safely, buying usually makes more sense in the short term. But I would not treat that as a trivial decision. I would look at customization limits, usage fees, reconciliation needs, tax requirements, and how much of that can turn into a bottleneck later. If the product’s differentiation depends a lot on billing logic, maybe buying the base and keeping the business rules closer to us is better than buying everything or building everything.”

That answer shows:

• the current objective
• hidden cost
• operational risk
• a possible hybrid path

Common mistakes

• Treating build vs buy as a question of technical pride.
• Looking only at entry cost and ignoring ongoing cost.
• Buying without considering lock-in and customization limits.
• Building without admitting that it becomes an internal product.
• Giving a universal rule instead of using context.

How a senior thinks

People who have matured usually think like this:

“If we build this, what exactly becomes our responsibility for years? If we buy it, what exactly moves out of our control?”

That is a very good question.

Because it forces the conversation out of the initial excitement and into real responsibility.

That is where the decision starts to become honest.

What the interviewer wants to see

The interviewer wants to see whether you:

• compare total cost, not just immediate cost
• think about speed and maintenance at the same time
• understand vendor risk and internal product risk
• consider company stage and team capacity
• avoid dogmatic answers

A strong answer can sound like this:

“When I think about build vs buy, I try not to treat it as engineering opinion or a pure spreadsheet exercise. First I make clear what we need to protect now. Then I compare time to value, maintenance cost, flexibility, dependency, and operational risk. For me, the question is not which option looks more elegant. It is which option creates the right kind of responsibility for the company’s stage.”

A poorly thought out build vs buy decision just trades one visible problem for another one that shows up later.

When you compare future responsibility, not just initial speed, the decision starts to look mature.