Build vs. Buy Isn't a Hard Decision. It's a Symptom.

At the start of this series I made the case that AI removed the friction that used to force teams into alignment, and that speed doesn't fix a fuzzy spec, it multiplies it. I closed that post by saying that once you actually do the alignment work, most of the decisions people agonize over get small.

This is the one I see people agonize over most.

Build it or buy it. I have watched teams burn a full quarter on this question. Spreadsheets with weighted scoring models nobody believes. Four vendor demos that all look the same by the third one. A Slack channel where the same two arguments get made in slightly different words every week. And at the end of it, a decision that gets made mostly by whoever got tired last.

I used to think that was a hard problem. It isn't. The agony is not a sign that the decision is difficult. It's a sign that you're trying to answer a question downstream of one you skipped.

What the Paralysis Is Actually Telling You

Here is the pattern, and I have now seen enough versions of it that I trust it.

A team cannot decide between building something and buying it. So they go get more information. More demos, more reference calls, more comparison matrices. The information does not help. It never helps. They come back with more data and the same paralysis, and now they are three weeks poorer.

The reason more information does not resolve it is that they are not missing information about the vendors. They are missing a definition of what winning looks like.

When you cannot name your decision criteria, every option is simultaneously defensible and risky. Vendor A is defensible because it has the most features. It's risky because you might not need them. Building is defensible because you get exactly what you want. It's risky because you have to maintain it. All of those statements are true at the same time, forever, and no amount of additional vendor research collapses them.

Requirements are what collapse them. Not a feature wish list. Actual requirements, meaning: what this thing has to do for the business, which parts are non-negotiable, and how you will know in ninety days whether it worked.

Write those down and something slightly funny happens. Two thirds of the options disqualify themselves immediately, and the remaining ones are close enough that the decision stops mattering as much as you thought it did.

Cheap to Build Is Not Cheap to Own

There's a second thing driving this, and it's newer.

AI made building dramatically cheaper. Things that were obviously buy decisions two years ago because building them was a six month project are now genuinely buildable in a couple of weeks. That's real, and I've done it. The option set legitimately expanded.

But the cost that got cheaper is the day one cost. AI lowered the cost of building. It has not done much to lower the cost of owning.

Day four hundred still has the same bill it always did. Somebody patches the dependencies. Somebody handles the security review when a customer's procurement team asks. Somebody is on call when it breaks on a holiday weekend. Somebody keeps it compliant when the regulation shifts. Somebody has to still be here, and still care, and still remember why it was built the way it was.

That column did not shrink. If anything it got worse, because it's now easier to accumulate more of these things than you have the capacity to carry.

So when the build column looks suspiciously cheap now, check whether you priced the whole life of the thing or just the part where it gets written.

The Three Questions That Actually Decide It

Once the requirements exist, this comes down to three questions, and they take about an hour, not a quarter.

Is this your differentiator? Not is it important. Important is not the bar. The bar is whether a customer would notice, and care, if you did this materially better than everyone else. Billing is important. Nobody chose you because of your billing. Build what makes you different, buy what makes you functional.

Does something on the market already cover the requirements you can actually name? Not the requirements you might have someday. The ones on the page. If a vendor covers eighty percent of what you wrote down, the honest question is whether the missing twenty percent is worth owning a whole system for. Usually it isn't. Occasionally it is exactly the differentiator from the first question, which makes the answer obvious.

What does leaving cost? This is the one people skip, and it's the one that actually matters. Exit cost is rarely about the contract. It's about your data and your integration surface. Can you get your data out in a usable shape? How many places in your product know this vendor's name? That's your real lock-in, and it's mostly under your control, not theirs.

Keep the Seam Clean and the Decision Stays Reversible

That last question points at the highest leverage thing in this entire discussion, and it's an engineering decision, not a procurement one.

Most vendor decisions are two-way doors that teams dress up as one-way doors. What turns a reversible choice into an irreversible one is almost never the vendor. It's that you let their model leak into thirty files across your codebase, so switching means rewriting your product instead of rewriting an adapter.

Put the vendor behind your own interface. Define the thing your product needs in your language, then implement that interface against whoever you picked. It costs you a little upfront and it buys you the right to be wrong. That's usually the best trade available, because you will be wrong about a vendor eventually, and the question is only whether being wrong costs you a week or a quarter.

Do that, and the decision genuinely becomes small. You picked, you can unpick, move on to the work that actually differentiates you.

Go Upstream

If your team is stuck on build versus buy right now, I'd resist the urge to schedule one more demo.

Go back to the requirements. Not the wish list, the requirements. What does this need to do, which parts are non-negotiable, what does success look like in ninety days, and how much would it hurt to switch. Nine times out of ten the decision resolves itself in that conversation, and you'll notice the vendors were never really the problem.

This is the whole reason Discover exists as its own phase in how I run engagements, and why I keep pushing back when a client wants to skip it and start building. Structure first, tooling second. That has not changed. It just got more expensive to ignore.

If you're in the middle of one of these and it's been going on longer than it should, that's usually a good sign the conversation you need is a level up from the one you're having. That's the conversation I like having. Genesis 37 Labs exists for exactly that part.