The original argument
Back in 2022, I wrote about when to build vs buy technology for an analytics team at Clearbit. The gist was practical: understand your team's capacity, weigh the maintenance burden, and don't build what you can buy unless you have a genuinely unique need.
That still holds. But the landscape has shifted enough that the thinking needs updating.
Building is easier than ever. That's the problem.
AI has made it trivially easy to spin up basic apps and internal tools. What used to take a team two weeks can be prototyped in an afternoon. That speed is exciting - and dangerous.
Because easier to build doesn't mean you should build it.
I'm seeing this pattern everywhere now: someone on the team spins up a quick tool to solve their problem. It works. They're happy. Then someone else on another team builds a slightly different version of the same thing. And another. Now you've got three tools doing roughly the same job, none of them talking to each other, and nobody knows which one has the right numbers.
The new cost isn't building. It's maintaining.
Here's what people miss about AI-assisted development: the initial build is cheap. The ongoing cost is not.
Every internal tool you spin up needs:
- Observability. Is it actually working? Are the outputs accurate? Who's monitoring it?
- Maintenance. APIs change. Data sources shift. Models drift. That quick prototype is now a production dependency that someone has to keep alive.
- The real cost isn't tokens - it's everything around them. Labour to build it, tokens to run it, time to maintain it. Most people see the cheap prototype and assume it stays cheap.
- Documentation and handoff. When the person who built it leaves or moves on, can someone else pick it up? Pet projects become orphaned projects fast.
The tech debt math hasn't changed. AI just lets you accumulate it faster.
The real shift: internal marketing matters more now
This is the part I didn't see coming. When building is this easy, the bottleneck isn't capability - it's awareness. The reason three people build the same tool isn't that they can't build. It's that they don't know the other versions exist.
That means the build vs buy question now has a third option: build once and actually tell people about it.
Internal championing matters now. If you build something useful, you have to actually tell people it exists. Otherwise someone else will just build their own version next month. A few things that help:
- Catalog what exists. Before anyone builds anything, they should be able to check what's already been built. This sounds obvious. Almost nobody does it.
- Make internal tools discoverable. A tool nobody knows about is a tool that will get rebuilt from scratch next quarter.
- Sell the value. If you've built something good, put it in front of people. Demo it. Write a one-pager. Put it in Slack.
You need to know what's running
When your company has a growing number of internal apps and AI-powered workflows, you can't just hope they're working. You need to know:
- What's running and who's using it
- Whether the outputs are accurate and consistent
- What it costs to operate
- When it breaks - before someone makes a decision based on bad data
This is where I'd focus investment now. Not on building more tools. On making sure the tools you have are visible, reliable, and not duplicating effort.
Questions to ask yourself
There's no perfect flowchart for this. Every situation is different. But there are a handful of questions that consistently help.
A few things worth calling out:
Building has a cost too. People fixate on the price tag of buying but forget that building pulls engineers off other work. There's the time to build it, the time to maintain it, and whatever your team isn't doing instead. Price both options honestly.
If it won't move the needle, reconsider. Not every problem needs new tooling. If the impact isn't material, maybe the answer is neither build nor buy - it's do nothing for now.
Maintenance is the real question. Most people skip it. Building is the fun part. Keeping it alive six months later when the person who built it has moved on - that's the actual cost.
The build vs buy game has changed because building is cheap. But cheap to start and cheap to run are very different things. The companies that get this right won't be the ones building the most. They'll be the ones building deliberately - and making sure nothing gets rebuilt twice.