Buy vs. build: the argument you need to get better at this year

AI made building easier. It didn't make owning it easier — and that's your whole argument.

Aug 30, 2026

Hi friends - I plan to spend the next few weeks talking about positioning. One common trend I’ve seen over the past 4+ years is that most founders orient their positioning against an incomplete set of options.

When you write your competitive positioning, you’re almost always writing against your direct competitors. Logo grid, feature comparison, us-versus-them. But that’s not the full suite of choices sitting in front of your buyer. Your buyer is choosing between four things:

Doing nothing at all (aka cost of inaction)
Throwing people at the problem instead of software
Building it themselves
And then — only then — you versus your direct competitors

Most of your deals are lost in the first three, not the fourth. And today I want to go deep on number three, because it’s the one that has changed the most in the last eighteen months.

Buy vs. build: the argument you need to get better at this year

Buy vs. build has always been part of B2B selling. If you sell software to companies that employ engineers, someone in that building has said “we could just build this” at least once.

What’s different now is that they might be right about the building part and the timeline is far shorter than it’s ever been.

AI coding tools have genuinely collapsed the time it takes to get from nothing to something that works. A two-person (or even one-person) team can stand up a functional internal tool in a weekend that would have taken a quarter three years ago. That’s real. Pretending it isn’t is delusional and will cost you credibility.

But here’s the other reality: AI compressed the build. It did not compress the cost of ownership equally.

The weekend prototype is the cheapest, easiest, and least important part of what your product actually is. Everything expensive comes after — the integrations that break when a vendor changes their API, the compliance requirements that shift, the edge cases nobody scoped, the person who has to own it in eighteen months when the engineer who built it has moved on.

Your positioning against building used to be “this is hard to build.” That argument is weakening. The new argument is “this is hard to own.” And it’s a much better one, because it’s true and it gets truer over time.

The arguments that actually work

I’ve written many build-vs-buy pieces for clients, but here are two examples — one for a warranty claims platform and one for an FX operations platform. Completely different industries, completely different buyers. The arguments that landed were nearly identical.

Here they are, in the order I’d use them.

1. The build number is never the real number

This is the one every buyer gets wrong. They scope a loosely defined set of requirements, get a number, and compare it to your annual contract value. You may very well lose that comparison, but you’re being compared against a fantasy.

The line I’d steal: you’re not funding a project with a completion date, you’re funding a permanent engineering team.

Software doesn’t sit still. Regulations change. Integrations need to be maintained. Your buyer’s own business adds a product line and now the tool needs to handle it. Every one of those is a ticket, and tickets need an owner.

The move: make them do a five-year total cost of ownership comparison, with a standing headcount line in it. If their build estimate doesn’t include the people who keep it alive, it isn’t an estimate yet. This is a genuinely helpful exercise for them even if they don’t buy from you — which is exactly why it works.

2. Quality isn’t a talent problem, it’s a variance problem

Be careful here, because this is where you could sound condescending. You are not saying their engineers aren’t good.

You’re saying their company isn’t organized to be excellent at this (building whatever you sell). A business built to underwrite risk, or move freight, or run clinics, will produce some software of unpredictable quality — and the unpredictability is the actual risk. They might have an IT team, not a product management organization. Those are two different things.

It might come out great! They won’t find out until the money is already spent. Said that way, it’s not a shot at their team. It’s a comment on where their organizational muscle actually is.

3. Their engineers should be building something else

There is another argument to be made about their engineering team, too. One way to explain it is to split their business into two buckets: the things that make them different from the company down the street, and the plumbing that just has to work.

Ask which bucket your category lives in. If you sell claims processing, or FX settlement, or expense approvals — most of your buyers didn’t build a business to be excellent at that. If they did build it, they did it because nothing good enough existed to buy. It’s the same reason companies used to build their own CRMs, right up until buying one became obviously correct (hint: Salesforce, HubSpot, etc). It’s the same reason no one is building their own Slack or Teams today.

So if your buyer wants to be a technology company, encourage it. Genuinely. Just point that engineering capacity at the things that are actually a competitive differentiator for their growth, revenue, and customers - not their cost to serve or profit margins.

4. They’ll only ever learn from their own data

This is the strongest argument in the set and the one I see used least.

Whatever their internal tool figures out, it figures out from their volume, on their timeline, and they pay for that discovery once, alone. Meanwhile a peer two states over is running the same experiment on their own data, hitting most of the same walls, a quarter ahead or a quarter behind — and neither of them ever finds out.

You’ve already paid for those lessons across every customer you have. That accumulated pattern recognition is not a feature they can build. It’s the thing they’re actually buying, and almost nobody says it out loud.

5. The roadmap slot they may never win

Ask your champion a question: where does this sit on the engineering roadmap, and do you control that roadmap?

Very often in my experience, the answer is no. The people who feel the pain most acutely have the least influence over what engineering actually builds. Their project competes against a compliance requirement, the customer portal, and any number of other internal initiatives. It’s hard to compete for internal resources. “We could build that” quietly becomes “we’ll get to it,” and then it just never happens.

This isn’t a hypothetical you have to argue. It’s a question you ask, and they answer it for themselves.

6. Concede flexibility, out loud, early

Nothing will fit their specific workflow like something built to their exact spec. That’s true. Say it.

The best-performing section of the warranty piece I helped write opens by admitting the build case is stronger than most vendors will admit — and the author leads with the fact that he made the build call himself at a previous company, and it was the right one at the time.

A buyer who’s already leaning toward building will bounce off a piece that pretends building is completely out of the question. Concede the real advantage, then show them the price of it. You can’t argue someone out of a position you refuse to acknowledge they hold.

Two structural moves worth copying

Beyond the arguments themselves, both of those pieces do something you should steal.

They refuse the binary. The warranty piece opens with “there are three options, not two” — build, replace, or run something on top of what you already have. The FX piece quietly splits “buy” into legacy platforms and modern ones. In both cases, the third option the writer introduces is, conveniently, the exact category they compete in.

That’s positioning doing its actual job. You’re not winning an apples to apples comparison — you’re redrawing the comparison so the thing you do best is a category of its own, not a feature.

They warn about the wrong purchase, not just the wrong build. Both pieces spend real estate cautioning against long implementations, thin APIs, and platforms with no ongoing development. Arguing against a bad version of buying makes the case for good buying far more credible than arguing that all buying is good.

Founder Self-Check

Run yourself through these honestly:

When you lose a deal to “we’re going to build it,” do you know whether they actually did?
Can you name the five-year cost of your buyers building your product themselves?
Do you have anything in writing you can send a technical buyer who’s pushing for a build?
What’s the honest, strongest case for them building it — and can you say it out loud?

Where to start

Write a similar article presenting your argument on buy vs build. Seriously — this is the whole recommended action.

Almost every founder I work with has these arguments in their brain. They come out on calls, and maybe they’re scattered through a sales deck. Very few have the full argument written down in one place, which means it only ever gets made when the founder is in the room.

A single honest build-vs-buy article does an absurd amount of work:

It handles the objection while you sleep. Your champion has to sell this internally to a CTO you’ll never meet. Give them ammunition they can forward.
It’s sales enablement for a rep who can’t argue it as well as you can. This is one of the assets you build before you hire, not after.
It’s a top-of-funnel search play. “Build vs. buy [your category]” is often a real query with real volume, and it’s asked at exactly the moment someone is deciding.
It’s an AEO play too. Your buyer’s engineering lead is asking ChatGPT whether they should build this. Someone’s content is shaping that answer. It should be yours.

That’s a GTM multivitamin if I’ve ever seen one — one asset, four jobs.

Good, better, best on execution:

Good. Write it yourself, fast and honest. Open by conceding the real case for building. Walk through the five-year cost. End with the questions you’d want them to ask if you were on their side of the table.

Better. Interview the person on your team who has actually made this decision from the buyer’s seat — a former operator, an advisor, a customer who tried building first and stopped. That perspective is the whole credibility engine, and it’s why the warranty piece works. Record it, then let AI do the first draft letting you keep the operator’s point of view.

Best. Turn it into a real decision tool. A scoring table across your options — time to something working, five-year cost, flexibility, cost of being wrong. Buyers will screenshot that table and paste it into their internal deck, and now you’re in a meeting you weren’t invited to.

And if you want to go one step further: the strongest version of this argument isn’t a document at all, it’s a number. Offer to run their actual data and show them what the problem is costing them today.

More to come on positioning next week!

And if you write one of these, send it to me. I’d genuinely love to read it.

With love and gratitude -