Engineering Strategy: Buy vs. Build

The most expensive mistake in tech isn’t picking the wrong database. It’s picking the wrong battle.

Every line of code your team writes is a future liability. Every custom-built system is a maintenance tax that your company will pay for the lifetime of the product. As a Principal Engineer, my primary job is not just to deliver software. It is to protect the company’s ability to win. If we are building things that don’t make us unique, we aren’t innovating. We are just creating overhead.

What is the secret sauce

When a Product Manager or a Lead Engineer suggests building a custom solution, they are usually focused on the perfect fit. To make sure the business wins, I have to focus on the opportunity cost.

The rules are simple:

• Build the Core: If the technology provides a unique competitive advantage, the capability that makes customers choose us over a competitor, we build it. This is where we want our best minds focused.

• Buy the Context: If the technology is a standard industry requirement (Auth, Payments, CRM, Messaging), we buy it. Building a custom billing system does not make us a better Fintech or AI company. It creates a maintenance burden that steals velocity from the work that actually differentiates us.

The Framework: The Core vs. Context Matrix

To make this decision objective rather than emotional, I use the Core vs. Context Matrix, inspired by the Eisenhower matrix. It forces us to ask two questions:

• Is this mission-critical? (e.g. if it’s down, we can’t sell or serve customers, or we breach legal requirements or SLAs)

• And does it differentiate us? (e.g. it changes win-rate, retention, or unit economics in a way competitors can’t easily copy)

Two caveats.

Not all decisions are equal. Some are easy to undo, while others become permanent architecture. When a decision is hard to reverse, we bias toward proven vendors. When it is reversible, we can afford to experiment and learn quickly. A useful heuristic is this: if it would take quarters and a migration to undo, treat it as irreversible.

The Non-critical + Differentiating quadrant is essentially Research and Development. My experience as a professional researcher taught me that this is the preferred hiding spot for pet projects. These investments must be time-boxed with explicit success criteria to avoid a backlog of never-ending experiments.

Building the Core

Even when the matrix says Build, the trap is overbuilding. A Principal Engineer avoids the perfect fit fallacy by focusing on opportunity cost. When we decide to build the Core, we must do it with lean execution.

• Define interfaces early to allow parallel work

• Build thin and iterate fast to prove the differentiation hypothesis

• Instrument heavily to see if the custom build is actually moving the needle

• Invest in testability and operability from day one to prevent the system from becoming a burden

The Maintenance Tax

Engineers love to build. Teams often believe they can do better or cheaper than a vendor. But the sticker price of a vendor is often lower than the Total Cost of Ownership (TCO) in the early years. When you build Context, you are paying for future security patches and documentation that a specialized vendor would have already provided. I would rather pay a vendor to handle the boring complexity of global tax compliance so my engineers can focus on work that provides value to the business.

Buying is Not a Silver Bullet: The Integration Tax

Buying has its own risks. As I discussed in my previous post on evaluating software vendors. the Buy path introduces the Integration Tax. You must watch out for:

• Operational coupling: A vendor outage becomes your outage

• Data model mismatch: Forcing your logic into a vendor’s rigid schema

• Observability gaps: The system becomes a black box when things go wrong

• Contract and Security review overhead: The hidden time spent with legal and compliance

Even with these risks, a complex buy is usually safer than a distracted build. When we buy Context, we are buying time. In a high growth environment, time is the only resource we cannot manufacture.

Adopt + Integrate

Sometimes the best answer is Adopt + Integrate. This means adopting a market leader and integrating it deeply enough to meet product needs without owning the full complexity. You buy the foundation (Stripe, Okta, AWS) and build a thin abstraction layer around it. This allows you to own the workflows and data model boundaries while preserving an exit strategy by designing for migration up front. This approach works best when:

• The capability is Context, but must feel seamless in the product experience

• The vendor solves most of the problem, and the remaining gap is specific to your workflow

• The system needs strong internal controls, observability, and governance

The Context to Core transition

A common misconception, especially in the cloud-computing age, is that infrastructure is never Core. However, you must also recognize that some foundations become differentiating as the company scales. For instance, infrastructure cost efficiency becomes a competitive advantage for high-volume platforms. Latency can become a product feature in fintech. In these cases, what started as a Buy decision may eventually need to move to a Build strategy to protect your unit economics or performance edge.

Decision Checklist for Your Next Meeting

Use these five questions to audit your next Build vs. Buy proposal:

1. Differentiation: Does this feature help us win a deal or retain a customer in a way a vendor cannot?

2. Time to Value: Can a vendor get us to market in weeks instead of the quarters a custom build would take?

3. The Maintenance Owner: Who is the named engineer responsible for security patches and updates for this custom system in two years?

4. Reversibility: If we build this and fail, or buy this and it sucks, how hard is it to switch?

5. The Exit Strategy: If the vendor triples their price or goes bankrupt, do we have a plan to migrate?

6. Data Ownership and Portability: If we need to leave this vendor, can we export our data in a complete, usable format, and migrate without losing history, integrity, or critical workflows?

The Real Outcome

The goal of a Buy vs. Build strategy isn’t to save money in the short term. It’s to ensure that when we do decide to build, we are doing it with maximum focus and zero distractions.

We buy the foundations so we can build the skyscraper.