Build Less, Buy Less

The build versus buy question has been settled the same way for about twenty years. You buy. You are not a software company, your time is worth more than the license, go sell something.

That answer just got less obviously correct, and I have watched enough people overcorrect in the last six months that I want to talk about where the line actually sits now.

The trigger is a number. Roughly a third of organizations have skipped buying at least one piece of software this year because they could build the thing themselves with agentic coding tools. Not evaluated and decided against. Skipped. Never entered the sales process.

That is a real shift and it is going to keep moving. It is also the setup for the most expensive mistake I expect to see people make over the next eighteen months.

Be precise about what changed, because the imprecise version leads people somewhere bad.

What got cheap is not software. What got cheap is the specific, narrow, unglamorous middle of software. The internal tool that takes data from one place, applies your particular rules, and puts it somewhere else. The dashboard nobody outside your company will ever see. The form that feeds a process only you run.

That category used to cost twelve thousand dollars and six weeks of a contractor, so you bought a product that did eighty percent of it and lived with the mismatch. Now it costs a weekend and somebody moderately technical, so the calculus flipped.

What did not get cheap is everything around that middle. Nobody automated maintenance. Nobody automated the security review, the compliance posture, the migration when a dependency breaks, the on call at two in the morning, or the institutional knowledge that walks out the door when the person who wrote it leaves.

The building got ten times faster. The owning did not get faster at all.

That is the whole thing. That is the entire strategic picture and if you hold onto only one sentence from today, hold that one.

Somebody builds an internal tool in a weekend. It works. It is genuinely better than the product they were paying for because it fits their process exactly.

Eleven months later I am sitting across from them and they have fourteen of these. Nobody remembers how four of them work. Two broke when a provider changed an endpoint and got quietly abandoned, and the process they supported reverted to a spreadsheet somebody maintains by hand. One is doing something with customer data that would not survive a serious question. And the person who built most of them is now spending a third of their week keeping them alive, which was never anybody's plan.

The individual decisions were each correct. The portfolio is a mess.

That is the failure mode. Not one bad build. A drift where every build was defensible in isolation and nobody was ever accountable for the total.

Before you build anything, three questions. If you get an uncomfortable answer to any of them, buy.

One. Will this need to change when the world changes?

Some tools are frozen. They implement a rule that is yours and stable. Route these leads this way. Format this export like this. Nothing outside your company can force a change.

Other tools are exposed. They touch tax rules, payment processing, email deliverability, platform APIs, compliance requirements, anything that a third party can alter without asking you. Every one of those changes is a maintenance event you now own forever.

Build the frozen ones. Buy the exposed ones. When you buy an exposed tool, a big part of what you are paying for is a company whose entire job is noticing that something changed and fixing it before you knew.

Two. What happens to this when the person who built it leaves?

Answer honestly and out loud.

If the answer is "somebody else could pick it up in an afternoon," build.

If the answer involves a specific person's name and a wince, do not build it, or build it with a documentation requirement enforced at the same level as the code. The tool that only one person understands is not an asset. It is a liability with good uptime.

The AI angle here is genuinely helpful and underused. The same tools that let you build fast will also document what you built, generate the runbook, and explain a codebase to the next person. Almost nobody does this because it is not fun and there is no deadline attached. Make it part of the build or you have not finished.

Three. Is this thing close to what you sell?

The closer a tool sits to your actual differentiation, the better the case for building it. Because the mismatch between a generic product and your specific process is exactly where your advantage lives, and buying a tool that flattens your process into the industry standard shape flattens your advantage with it.

The further it sits, the better the case for buying. Nobody has ever won a market on a superior internal expense approval flow.

Draw the line by asking whether a customer would ever notice the difference. If a customer could feel the difference between your version and the generic one, build. If not, buy, and stop thinking about it.

Here is the part I actually wanted to write today.

There is a third answer and it beats both of the other two more often than anybody admits. Do not build it. Do not buy it. Delete the process.

A meaningful share of the tooling in most businesses exists to manage complexity that should not exist. The approval flow exists because somebody made a bad call in 2023. The reporting tool exists because two departments will not agree on a definition. The integration exists because you are running two systems that do the same thing for historical reasons nobody can explain.

Automating that is not progress. It is making the wrong thing efficient, which is worse than leaving it slow, because slow things eventually annoy somebody enough to get fixed and efficient things persist forever.

Before build or buy, ask what happens if this simply stops. Not rhetorically. Actually trace it. Sometimes the answer is that three people are relieved and one report nobody reads goes away.

I run this on every process once a year and it kills about one in six. That is the highest return activity in my entire operation and it costs nothing but the willingness to look stupid for suggesting it.

FROM THE AI NEWSROOM

The exact systems behind everything in this issue. Routing tables, gate logic, the scenario templates, and the review cadences, built out step by step so you can copy them straight into your own stack. One time, forty seven dollars.

Get the Blueprint for $47

.....

There is a second finding in that same research that got less attention and matters more.

Large enterprises scaling AI agents in one or more functions went from twenty seven percent to forty percent. Smaller firms stayed flat at twenty two percent.

Read that again. The big companies moved thirteen points. The small ones moved zero.

That is backwards from how this was supposed to go. Small companies are supposed to be the fast ones. No procurement committee, no change management, no legal review, decide on Tuesday and ship on Thursday. Every structural advantage points to small firms adopting faster.

They did not. And it is not cost, because the tools are cheap. It is not access, because the tools are on the open internet.

It is attention. The owner of a twelve person company is doing sales, delivery, and hiring, and the thirteen point move requires somebody whose job is to move it. Big companies hired that person. Small companies did not, because it does not obviously pay for itself in month one.

If you are small, that gap is your problem and your opportunity in the same breath. Everyone your size is also not doing it. The bar to be ahead of your peer group is astonishingly low right now and it will not stay low.

The version of this that works is boring and it is a standing block of time, not a project.

Four hours a month. One block, on the calendar, protected the way you protect a client call. Not for building. For looking.

In that block you do three things. You review the list of internal tools you own and mark any that are unmaintained or unowned. You pick one process and ask whether it should exist. And you pick exactly one thing to build or buy before the next block.

One per month. Twelve a year. That pace sounds slow next to a weekend where you built four things, and it will put you further ahead in two years, because twelve owned and documented tools beat forty orphaned ones by an enormous margin.

If you want the infrastructure side of that handled without building it, Make.com covers most of what small operators end up building badly. The honest calculation is that if the thing you are about to build is mostly moving data between two systems with a few rules in the middle, that is a bought problem, and you should spend your build budget somewhere your customers can feel it.

One artifact makes all of this work and it takes an hour to create.

A single list of every internal tool and automation you own. Six columns.

What it does, in one sentence. Who owns it, by name. What breaks if it stops. When it was last touched. What it depends on that you do not control. Whether it should still exist.

That is it. One page, or one Notion database if you prefer.

The reason this works is not organization. It is that the last column forces an annual decision, and an unmade decision is how you get from four tools to forty without noticing. When something has been on that list for a year with nobody touching it and nobody able to say what breaks if it stops, you have learned everything you need to know.

Most people's honest version of this list has three or four rows they cannot fill in. Those rows are the whole point of making it.

The old advice was buy, because building was expensive.

The new advice is not build, because building got cheap. The new advice is own less, because owning never got cheap and now you can accumulate things to own at ten times the previous rate.

Build the narrow things that are frozen, close to what you sell, and understandable by somebody other than the person who wrote them. Buy the exposed things and the far ones. Delete more than you think you should. And keep a list, because the portfolio is the thing that kills you, never the individual decision.

A third of companies stopped buying software this year. Some of them made a great call. Some of them just traded a predictable monthly invoice for an unpredictable permanent obligation and have not gotten the bill yet.

Know which one you are before you build the next thing.

FROM THE AI NEWSROOM

For operators who would rather build it with someone than build it alone. The full stack, installed alongside you, with the decisions made in the room instead of guessed at. Ninety seven dollars.

Join the Accelerator for $97

.....

Make the list. Not the good version. The rough version, in whatever you have open.

Every internal tool, automation, scenario, and script your business depends on. Name it and name its owner.

If the list is longer than you expected, that is the finding. If there are rows where the owner column is blank or says "me, I guess," that is the other finding.

Twenty minutes. It is the most useful twenty minutes you will spend this quarter and it does not require you to decide anything yet.

Jordan

The AI Newsroom | Practical AI for people with a business to run.