There is a question you have almost certainly asked yourself, probably at 11 p.m., probably in a document titled something like "Options." Do you build this thing, do you buy it, or do you bring in a pod to build it with you? The question feels tactical. It is actually a question about where your team's effort should go, and effort, as it turns out, is the whole game.

Consider what the odds look like when effort is aimed at the wrong target. In a study of more than 5,400 large IT projects conducted by McKinsey with the University of Oxford, the average project ran 45 percent over budget and 7 percent over schedule while delivering 56 percent less value than predicted. Software projects carried the highest risk of all. And 17 percent of these efforts went so badly they threatened the existence of the company that attempted them. That is not a story about lazy teams or bad engineers. It is a story about talented people pouring enormous effort into the wrong model for the work in front of them.

So before you decide how to deliver, it helps to get honest about what you are actually delivering, and why it matters.

Start with a harder question than "can we build it?"

Of course you can build it. Your engineers are good. That is not in doubt, and it is also not the point. The more useful question is the one Geoffrey Moore posed years ago when he separated a company's work into "core" and "context." Core is the work that differentiates you, the work customers would notice if you did it better or worse than anyone else. Context is everything else that has to happen but earns you nothing special when it goes well: billing, authentication, log aggregation, the hundredth CRUD screen.

Here is the trap. Effort spent on context feels like progress because it is hard and it is yours. But difficulty is not the same as value. Marc Andreessen argued in 2011 that software would eat the world, and it has, which means the components you might build from scratch have mostly already been built by someone whose entire company is that component. When you build context yourself, you are not just spending this quarter's engineering hours. You are signing up to maintain, secure, and staff that thing forever.

The discipline, then, is to ask of every candidate: is this core or context for us? Your answer should sort most of the decision before you ever compare vendors.

Buy when the problem is solved and boring

If a capability is context, and a mature product already exists for it, buying is usually the move that frees your best people for the work only you can do. This is not surrender. It is grit applied correctly. Angela Duckworth's research on high achievers found that they are not the people who try hardest at everything. They are the people who choose one hard thing that matters and pursue it with unusual consistency. Buying the boring stuff is how you protect that consistency.

Where buying goes wrong is when you treat "boring" as "irrelevant." A vendor tool you cannot integrate, cannot extract your data from, or cannot bend to a workflow your customers depend on is not a bargain. Before you buy, you will want to pressure-test three things: total cost over several years rather than the sticker price, the exit path if the relationship sours, and whether the seams between the tool and your product touch anything you consider core. If they do, you may be buying context that quietly became core when you were not looking.

Build when the work is yours to own

Build when the capability is core, when it is a genuine source of advantage, and when owning it end to end lets you move in ways a vendor never could. Building is the right kind of hard.

Two old warnings deserve your attention here, because both come from watching capable teams struggle. The first is Brooks's Law, from Fred Brooks's 1975 book The Mythical Man-Month: adding people to a late software project tends to make it later. Communication overhead grows faster than output, so scaling a build is not a matter of throwing bodies at it. The second is Conway's Law, articulated by Melvin Conway in 1968: organizations produce designs that copy their own communication structures. If your teams are fragmented, your architecture will be too, whether you meant it to be or not.

The practical reading of both laws is the same. When you build core software, you are not just funding code. You are funding a team that can hold the whole problem in its head, communicate cleanly, and stay with the work long enough to compound. If you cannot commit to that, the build will drift, and drift is where those McKinsey overruns are born.

The pod: a third option that is often the wisest

Sometimes the capability is core, so buying feels wrong, but you lack the team, the specialized skill, or the runway to build well right now. This is where a delivery pod earns its place. A pod is a small, cross-functional, durable team, typically engineers, a designer, and a delivery lead, that owns an outcome rather than a pile of tickets. You are not renting hands. You are borrowing a working team that already knows how to work.

The research on why this structure performs is unusually clear. In Accelerate, Nicole Forsgren, Jez Humble, and Gene Kim showed through years of DORA data that the strongest predictor of delivery performance is not company size or industry but small, autonomous teams empowered to ship independently. Team Topologies, by Matthew Skelton and Manuel Pais, gives the shape a name: the "stream-aligned team," organized around a single flow of work and protected from more cognitive load than it can carry. A good pod is exactly that, and it sidesteps Brooks's Law because it is small by design and Conway's Law because it is structured to mirror the architecture you actually want.

The honest caution is ownership. A pod delivers its best value when knowledge transfers to you along the way, not when it walks out the door with the only mental model of your system. So the questions to ask a pod partner are less about velocity and more about handoff: how will your people learn this as it is built, and what does the day look like when the pod is gone?

A way to decide

Sort the capability into core or context first. If it is context and a mature product exists, buy, and spend the savings on what differentiates you. If it is core and you have a team that can own it for the long haul, build. If it is core but you cannot yet build it well, bring in a pod, and treat knowledge transfer as part of the deliverable rather than a nicety.

None of these is a moral choice, and none is permanent. The teams that defy the grim base rates are not the ones with the cleverest architecture. They are the ones who kept asking, quarter after quarter, whether their effort was aimed at the work that mattered. That habit of clear-eyed reassessment, more than any framework, is what separates the projects that deliver from the 56 percent that quietly do not.