Show Me the Data: An Engineering Leader’s Framework for Build vs Buy Decisions

Last updated: June 26, 2026

Last updated: June 26, 2026

A build vs buy framework is a short, repeatable test for deciding whether to build a capability in-house or rent it from a vendor. Mine runs on five numbers. If your team cannot put those numbers on the table, you are not ready to make the call yet.

A few years back I sat in an architecture review where a sharp staff engineer pitched building our own notification service. Replace the vendor. Own the whole thing. The deck was genuinely good, real sequence diagrams and clean boxes, and for about ninety seconds I wanted to say yes too, because building is the fun part and every engineer in that room knew it.

Then I asked three questions. What does this cost us over three years and not just to ship version one? When does the first real message actually leave the building? And who is carrying the pager at 2 a.m. eighteen months from now, when it falls over in the middle of a month-end run and the person who built it has long since left for a startup?

Silence. Not because the engineer was wrong, but because nobody had done the arithmetic, and a design with a feeling attached is not the same thing as a decision. So I said what I always say. Show me the data.

That phrase is the whole job, honestly. The framework below is what I reach for when the call is mine to make, and it works the same whether the thing on the table is an in-house auth system, a homegrown data pipeline, a custom search index, or a payments stack you are itching to own. It is the general version of a fight I have written about in one specific arena, build vs buy in AI, where most pilots quietly die before they ever reach production. Same disease. Different room.

What Build vs Buy Actually Means

Build vs buy is the choice between developing a capability with your own engineers and licensing it from a vendor who already sells it. Build means you own the code, the data, and every line of maintenance from today until the day you finally turn it off. Buy means you rent the capability and let someone else carry the upkeep. Most honest answers land somewhere in the middle. They usually do.

And here is the trap that catches good teams. They compare the wrong two numbers, putting the cost of building version one next to the three-year price of a vendor, at which point building always looks like the bargain. It is not a bargain. You are pricing the wedding and forgetting the marriage. Big difference.

So I make people lay real numbers next to each other. Five of them. None of these require a crystal ball, and a competent team can rough all five out in an afternoon, as long as everyone in the room agrees to stop flattering the option they already picked on the drive in.

The Five Numbers I Put on the Table

This is the framework. Five numbers, asked in order, before a single line of code gets written or a single contract gets signed. The table is the short version. The arguing happens underneath it.

Number one. The three-year cost, not the sticker

The build estimate you get handed is almost always just the cost of version one. That is the single most expensive lie in our whole industry. The honest number is version one, plus maintenance every year after, plus the fully loaded cost of the engineers who keep the thing breathing once the applause dies down. And loaded cost is the part people fudge. Salary is maybe two-thirds of it. Benefits, equity, laptops, the seat license for every tool that engineer touches, and a slice of their manager’s attention make up the rest, and all of it recurs every single year whether or not a soul is looking at the line item.

Buy has a hidden column too, to be fair. The license is the obvious part, then comes integration, then the seat creep as you grow into it, then the cost of ripping it out later if the vendor lets you down. Put both options on a three-year line. Then watch how often the vendor you called expensive turns out to be the cheap one.

Number two. Time to value, and what the wait costs

A vendor can have you live in days. Days, sometimes hours. A serious build takes months, sometimes a couple of quarters, and that gap is never free, because every week you spend building is a week of revenue you did not earn, runway you quietly burned, or a competitor shipping the thing while your team is still arguing about the schema in sprint planning.

I have a particular soft spot for this number, and it comes from mortgage tech. Vendors love to quote an Encompass integration like it is a long weekend, plug it in, map a few fields, ship it. The real number, once you actually account for the field mapping and the edge cases and the compliance review nobody put on the slide, runs closer to two quarters than two weeks. Every veteran in that world knows it in their bones. The sales deck somehow never mentions it.

Number three. Edge or plumbing

Some capabilities are your actual advantage, and most are plumbing that every company on earth needs and exactly nobody pays you extra for. Fraud scoring built on data only you own is an edge. The login box is plumbing. Pure plumbing. So is sending a text, charging a card, and shipping logs to a dashboard so somebody can squint at a graph.

The whole test collapses into one question. Could a competitor buy the same result tomorrow, with a credit card and a weekend? If yes, it is plumbing, and you should rent it from Stripe or Auth0 or Datadog or whoever has spent ten years and a thousand engineers getting it right. Building plumbing is how genuinely smart teams pour a year into a slightly worse version of Twilio and call it strategy. Do not be that team.

Number four. Who owns it at 2 a.m.

This is the number everyone skips, and it is the one that quietly takes the building down. A build is not a project with a finish line. It is a hire. Someone owns that system for as long as it runs, patches it, answers for it when it dies on a holiday, and keeps owning it long after the clever engineer who wrote it has moved on and taken the whole mental model with them.

The data here is brutal and it is public. McKinsey surveyed CIOs and found that tech debt is worth 20 to 40 percent of the value of an entire technology estate, with another 10 to 20 percent of the new-work budget bled off just to keep old work alive. Pull back further and the number gets absurd. CISQ pegged the cost of poor software quality in the US at about $2.41 trillion in 2022 and named technical debt the single biggest thing stopping teams from changing the code they already have. Every system you choose to build adds a brick to that wall. Buying does not.

Number five. One-way door or two-way door

Jeff Bezos framed this one years ago and it never left my head. In his 2015 shareholder letter he split decisions into two kinds. A type one is a one-way door. Walk through, hate it, and there is no walking back. No do-overs. A type two is a two-way door, the kind you can reopen and stroll back out of if the other side disappoints.

Build vs buy is rarely the same door twice, and matching your effort to the door is most of the skill. Swapping one analytics tool for another is a two-way door, so quit agonizing and just pick one. Rebuilding your core ledger in-house is a one-way door, because the day real money starts flowing through it, you are not casually migrating off on a Friday afternoon. Most teams get this exactly backwards. They hold three meetings about the reversible call and greenlight the irreversible one on a hunch.

The Build Trap, Counted Out

Building seduces you because the first demo is so cheap. A strong engineer wires up something that looks magic over a weekend, the room claps, and a real decision gets made on a feeling instead of a number. Then the actual bill shows up. On a delay. The way these bills always do.

Because now you own it. The dependency you leaned on ships a breaking change at the worst possible moment. A library you never thought about goes unmaintained. The one person who held the whole design in their head leaves for more money, and their replacement is quietly terrified to touch any of it. None of that lands in the weekend demo. All of it lands in the three-year cost, which is the entire reason number one sits at the top of my list and not the bottom.

I love building things, so take this as a builder talking and not some buy-everything cynic. Twenty-five years writing code in regulated industries taught me to respect the maintenance bill the way you respect a loan, because the interest compounds whether or not you ever open the statement. That sounds like something a CFO would cross-stitch on a pillow. I stand by it anyway. The most common reason I watch teams stall is not some gnarly technical wall. It is that nobody made the build vs buy call honestly or early, which is really just a clarity problem wearing a technical costume.

When the Data Actually Says Build

Sometimes it does, and you should not flinch when it does. When a capability is genuinely your edge, rests on data nobody else can get to, and has to live deep in the core of how your business runs, building is the correct answer and renting it would be the malpractice. I have made that exact call, shipped it, and never regretted it. More than once, actually.

But be honest about what build commits you to. Not a sprint. A team. The moment you decide to build the thing that actually matters, you have made a hiring decision, and the architecture turns out to be the easy half. You now need senior people who will own a living system for years and not bolt at the first recruiter email, which makes it a software engineering staffing problem long before it is ever a technical one.

The smart move is to prove the thing before you bet the headcount on it. Bring in a senior engineer on a contract basis, ship one real production slice in front of real users, and measure one number that somebody in finance already loses sleep over. If it works, staff it properly as a direct hire and keep the person who built it. You will learn more from three weeks in production, with real users finding the edge cases you swore did not exist, than from three months of a pilot that never leaves the safety of staging.

What Leaders Ask Me Right Before They Decide

If I only remember one thing about build vs buy, what is it?

Compare three-year totals, never day-one estimates. Build looks cheap only because the sticker price quietly hides years of maintenance and the team you will hire to keep it running. Line up the real numbers and the vendor you called expensive is usually the actual bargain.

How do you put a real cost on a build you have not built yet?

Start with the engineering estimate, then add the parts nobody enjoys saying out loud. Take the loaded cost of the people who will maintain it, multiply by three years, and then add the integration and switching costs on the buy side so you are finally comparing the same thing. You will not be precise. You will be honest, and on this question honest is worth more than precise.

Is choosing buy just admitting your team is not good enough to build it?

Wrong way to look at it. Your best engineers are scarce and expensive, and aiming them at plumbing that every other company already rents is the actual waste of rare talent. Buy the login box. Buy the payments. Then spend that team on the one or two things only your company could ever build.

When does the data genuinely point to build?

When the capability is your competitive edge, leans on proprietary data, and has to wire deep into your core systems. If all three are true, build it and hold it close. If only one is true, you are usually just rationalizing a build you already wanted for reasons that have nothing to do with the spreadsheet.

We are a small team. Does this still apply to us?

More than it applies to anyone else. A small team has fewer hours and zero spare ones, so a wrong build hurts harder and for longer. The smallest teams I respect buy almost everything and build the single thing that is the whole reason a customer picks them. That focus is the entire advantage, and they guard it. Fiercely.

Start With the Number You Are Avoiding

If you are staring down a build vs buy decision right now, do not open with the architecture. Open with the five numbers, and start deliberately with whichever one your gut wants to skip, because that flinch is almost always the tell, pointing straight at the soft spot in the case you have already half-built in your head. Most bad builds were not decided in the review. They were decided on the drive in, and the review was theater.

And if the numbers really do say build, get the people right before you get the design right. A system with nobody left to run it is just a future outage with a launch party attached. Every time. The recruiters I work with at KORE1 fill IT and engineering roles in about 17 days on average, and 92 percent of those hires are still in the seat a year later, which is the deeply unglamorous part that actually keeps a build alive long after launch. If you are staffing one, talk to a recruiter who has placed teams built to own a system for the long haul, not just pass an interview.

Want to argue with the framework, or show me exactly where it falls apart? Connect with me on LinkedIn. Build vs buy is the question I get asked more than any other, and I am still sharpening how I answer it.

Related reading: Build vs Buy in AI: Why Most Pilots Die Before Production.