The Build vs. Buy Sphere: How to Defend Your Engineering Focus
Every technology leader faces the perpetual dilemma: Do we build this ourselves, or do we buy it off the shelf?
When engineering teams get this wrong, the consequences can be quite devastating. It is not just about licensing costs or wasted sprints; it is an opportunity cost problem. Every hour an expert engineer spends building a custom logging framework or a bespoke data pipeline is an hour stolen from the core intellectual property that actually drives company valuation and market differentiation.
To keep our teams laser-focused, I use a simple, three-tiered rubric for build-versus-buy decisions. Instead of viewing your software architecture as a flat matrix, think of it as a three-dimensional sphere.
Each layer represents a different architectural depth, a different cost of change, and a different relationship model. By treating your software stack like a planetary body, you protect the high-gravity center from being derailed by surface distractions.
The Spherical Layer Framework
1. The Core (The Center of Mass)
This is the dense, high-value engine at the absolute center of the sphere. This is the proprietary intellectual property that generates all the gravity (the valuation and unique market differentiation) for your company. We should focus the vast majority of our time and elite engineering talent here. We build only the things that we are uniquely qualified to do.
However, defending the Core is not about letting engineers chase overly clever or complex solutions. True engineering discipline means choosing pragmatic, outcome-oriented approaches over technical ego to maintain momentum.
The Amazon Lesson: The Power of the "Dumb" Approach.
In its early days, Amazon needed a way to put highly relevant product recommendations in front of customers. Trying to compute personalized product affinity matrices in real time for millions of users was incredibly processor-intensive, slow, and expensive.
Instead of building an incredibly complex, real-time calculation loop, the team took a highly pragmatic, batch-processed approach overnight. The logic was simple: look at all customers who have already bought a bat and a ball, and analyze what else they have in common. If the data showed that a measurable percentage of those buyers also bought a glove, we had a high-probability pattern.
We pre-computed these associations over a 24-hour period, assembling static HTML recommendation snippets ahead of time. The real-time system did not have to think; it just looked for a trigger. If a customer who had previously bought a bat and a ball started browsing anywhere in the "Sporting Goods" category, the system instantly injected that pre-assembled glove recommendation.
Was it wasteful? Technically, yes, because we threw away the vast majority of those pre-computed recommendations at the end of every day. But it was vastly less expensive than running real-time pattern-matching algorithms on every page load, and it allowed high-conversion detail pages to render instantly. Sometimes a blunt, brute-force batch approach is infinitely better for the business than a "clever" real-time one.
2. The Specialized Mantle (The Middle Layer)
This is the thick, heavy structural layer wrapping directly around your core. It includes deep infrastructure: databases, operating systems, cloud environments, and highly specialized enterprise software. It is not our core skill set. We use these tools heavily, but we are never going to build them ourselves.
Because this mantle physically supports your core, it carries a remarkably high cost of change. If you try to rip out a piece of the mantle, the whole sphere fractures. You go into these procurement cycles knowing you are locked into this structural layer for the long haul.
Therefore, your evaluation criteria here must shift from a standard feature checklist to a relationship-first framework. I am willing to pay a little more, or even accept slightly fewer raw features, as long as the vendor demonstrates an exceptional ability to maintain a collaborative partnership.
The Procurement "Test"
When evaluating these vendors, I always throw a curveball question into the procurement process. I will ask for a minor feature that they do not currently have.
I am not looking for a flat "no."
I am also not looking for them to promise to build a bespoke feature just for us, because custom enterprise development does not scale and is a massive red flag for their architectural health.
Instead, I am listening for their willingness to engage in a thoughtful, strategic dialogue. I want a partner who says, "Here is how that request fits into our broader product roadmap, and let us collaborate on a creative workaround for your immediate need." I want to know they care about understanding our engineering problems, not just selling licenses.
The Two-Way Mirror Review
Once you sign a strategic mantle vendor, you have to actively manage the relationship health. Every quarter, we hold a formal relationship performance review. We do not hide behind automated metrics; instead, we show up with exactly two slides:
Top 3 things that are working well.
Top 3 things that need improvement (including the specific business value those improvements will unlock for us).
Crucially, we then ask the vendor to present the same two slides to us. We explicitly tell them: We want you to be the best vendor to us, but we also want to be the best customer to you. This level of radical candor ensures that when friction inevitably arises, the partnership survives.
3. The Commodity Crust (The Outermost Shell)
This is the thin, interchangeable outermost layer of the sphere, containing software available from dozens of different alternatives all doing generally the same thing, like logging frameworks, basic email notification services, or indexing tools.
The beauty of the crust is that it is designed to shift and change. Because multiple options compete for your attention, you hold immense power during implementation and negotiations. The cost of change here is naturally low, meaning you can swap out components without affecting the underlying structure, assuming you remain disciplined.
The Junior Engineer Trap
Crust integrations are rarely handed to your most senior, battle-tested architects; those senior engineers are laser-focused on defending the Core. Instead, commodity tools are typically handed to more junior engineering staff.
This creates a hidden organizational risk. Commercial vendors know their software is a commodity, so they actively push proprietary extensions and unique features specifically designed to drive artificial lock-in. To a junior engineer, these shiny extensions are incredibly seductive. To a technology leader, they are dangerous.
The moment your team adopts a vendor's proprietary extension, that commodity tool begins to fuse to the mantle below. It creates a structural bridge where there should be a clean separation. The cost and complexity of migrating away skyrockets, and your leverage vanishes. Educating junior staff on this trap and strictly verifying that integrations remain modular and vanilla is a critical mentorship responsibility for engineering leadership.
What About Open Source Software?
But what if you bypass commercial vendors entirely? What about Open Source Software (OSS)?
It is easy to view open source as a free pass out of vendor lock-in. You do not license it from a third party via a cash transaction, but make no mistake: Open source is only free if your engineers' time has zero value. There are massive, ongoing structural costs involved.
When you pull down code from the open-source community, you are not just adopting a tool; you are adopting a lifecycle. You must:
Implement: Architect and configure the packages to safely fit your environment.
Maintain: Continuously monitor, test, and deploy new versions to address breaking changes.
Patch: Rapidly apply critical security fixes when vulnerabilities are exposed.
Extend: Fork or build wrappers around the code base to meet your company’s highly specific operational needs.
Look at the leading, bedrock works of the open-source community, which includes foundational systems like the Linux kernel, Kubernetes, or massive ecosystem frameworks. These projects are masterpieces of collective engineering, but keeping pace with them requires a relentless investment of human capital. If a critical bug limits your performance, or a major security vulnerability drops, you cannot open a high-priority support ticket with a vendor. Your team is the support team.
If your engineering resources are tied up continuously upstreaming patches, refactoring custom extensions to match a new OSS release, or managing complex dependencies, that open-source crust is no longer a cheap utility. It has become a massive internal engineering burden, quietly sucking energy away from your Core. Whether you pay with a corporate credit card or with raw engineering hours, the tax on your velocity remains the same.
Maintaining Structural Integrity
Engineering leadership is ultimately an exercise in resource allocation. By balancing your focus across these three layers, you build a protective buffer around your organization. You license or strictly scope the commodity crust to gain speed, build deep human relationships with your specialized mantle partners to ensure stability, and keep your most valuable engineering minds entirely focused on what matters most: winning the center of the sphere.