Mehmet Erturk | When to Build vs Buy

Build vs Buy

"Should we build this ourselves or use an existing solution?"

I get this question constantly. From engineers who want to build. From finance who wants to save money. From product who just wants it done.

The answer is always "it depends." But there's a framework for thinking about it.

The Default Should Be Buy

Controversial take for an engineer, but: your default should be to buy/use existing solutions.

Why?

Building is expensive. Not just initial development — maintenance, bug fixes, upgrades, documentation, on-call. Every custom system becomes technical debt to manage.

Building takes focus. Every custom system you build is attention not spent on your core product.

You're probably not special. That problem you think is unique? Hundreds of companies have solved it. Their solution is probably better than what you'd build.

Time matters. Buying gets you to market faster.

Start with buy. Only build when there's a compelling reason.

When to Build

That said, sometimes building is the right call.

1. It's Your Core Differentiator

If it's central to your competitive advantage, own it.

Netflix built their own recommendation engine
Stripe built their own payment processing
Google built their own search infrastructure

These weren't commodities for them — they were the product.

But be honest. Most things you think are differentiators aren't. "We do CRM slightly differently" doesn't justify building a CRM.

2. Nothing Exists That Fits

Sometimes the market doesn't have what you need:

Novel problem space
Unusual scale requirements
Specific integration needs that nothing addresses

But verify this. Actually evaluate options before concluding nothing fits. "I couldn't find anything" often means "I didn't look very hard."

3. The Cost of Integration Exceeds Building

Sometimes integrating an off-the-shelf solution is harder than building:

Vendor doesn't support your tech stack
Their data model doesn't match yours
Required customization approaches rebuilding it anyway

Calculate the real cost of integration, not just the sticker price.

4. Vendor Risk Is Unacceptable

If the vendor disappears, what happens?

Can you migrate off?
Would you be down until you rebuild?
Is the vendor stable?

For mission-critical systems with unstable vendors, building might be safer.

When to Buy

1. Commodity Infrastructure

Authentication. Payments. Email. Logging. Monitoring.

These are solved problems. Thousands of companies use the same solutions. You're not going to build better than Auth0 or Stripe or Datadog with a team of 5.

2. Not Your Expertise

If it's not what your team is good at, don't build it.

Building a custom database when you're a product team? Bad idea. Use Postgres.

Building custom ML infrastructure when you're an e-commerce company? Bad idea. Use a platform.

3. Speed Matters More Than Perfection

If you need something next month, buy it. You can always migrate later if it doesn't work out.

The cost of delay often exceeds the cost of imperfect fit.

4. Total Cost of Ownership Is Lower

Calculate real costs:

Building:

Initial development time
Ongoing maintenance (budget 20-30% of initial build, annually)
Opportunity cost of engineers not working on product
On-call burden
Documentation and training
Risk of bugs and outages

Buying:

License/subscription fees
Integration cost
Training
Vendor lock-in risk
Feature gaps requiring workarounds

Often, buying is cheaper even when the sticker price looks high.

The Hybrid Path

Sometimes the answer is neither pure build nor pure buy:

Buy and customize. Start with a vendor, build custom pieces on top.

Open source and host. Get the software free, pay for hosting/ops.

Build the glue. Buy commodities, build the integration layer.

This is often the best approach. Use existing solutions where possible, build only the pieces that truly differentiate.

My Decision Framework

For any build vs buy decision:

Is this core to our competitive advantage? If yes, lean build. If no, lean buy.
Does a good solution exist? Actually evaluate. Talk to vendors. Try free trials.
What's the real cost of each? Including maintenance, opportunity cost, risk.
What's the timeline pressure? If urgent, buy.
What's the team's expertise? Don't build what you don't know.
What's the vendor risk? Stability, lock-in, pricing power.

Score each option. The right answer usually becomes clear.

Common Mistakes

Engineers want to build everything. It's more fun. It's more interesting. But it's often not the right business decision.

Underestimating maintenance. Building seems cheap until you're maintaining it for years.

Overestimating uniqueness. "Our needs are special" is usually wrong.

Ignoring vendor risk. That startup with the great product might not exist next year.

Not calculating opportunity cost. What else could those engineers be doing?

The Conversation

When someone proposes building something, I ask:

What existing solutions did you evaluate?
Why don't they work?
What's the initial build cost?
What's the ongoing maintenance cost?
Who will own this long-term?
What's the opportunity cost?

If they can answer all of these compellingly, build. Otherwise, buy.

Building is seductive. There's satisfaction in crafting your own solution. But for most problems, someone else has already solved it better than you will. Use their work. Save your building energy for what truly matters.