For years, “build versus buy” was mostly a cost question. Building was expensive and slow, so the default was to buy, and you only built when you had no other choice. AI is dissolving that constraint — the cost and time to build are falling fast. Which means the old tie-breaker is disappearing, and a better question is taking its place.
The distinction that actually matters
Not all work deserves custom software. The useful line is between two kinds:
- Differentiating work — the things you do that are genuinely particular to your business, and part of why customers choose you. If a packaged product forces you to do this the same way as everyone else, it erodes the very thing that sets you apart.
- Common work — payroll, expense management, email, most accounting. Enormous, mature markets already model this well. Building your own is almost always a waste; buy it and move on.
Build where you’re differentiated. Buy where you’re common. Most of the build-versus-buy confusion comes from applying custom effort to common work, or forcing differentiating work into a generic tool because it was already on the shortlist.
“The users asked for it” is not a reason to build
The most seductive trap in software is a room full of experienced users with detailed requests. It feels like signal. It usually isn’t.
Over time, skilled people adapt themselves to the tools they’ve been given. Ask them what they need and many will describe the screens they use and the buttons they click — improvements to the software they already know, not the work the business actually needs done. Build to those requests and you automate the current tool, faithfully, including everything wrong with it.
The stronger question is the one behind the request: what are you actually trying to accomplish? Answer that — the job, not the interface — and you often find the real need is simpler, different, and sometimes already served by something you own. This is the same reasoning that governs should we replace our CRM?
What falling build costs change — and what they don’t
Cheaper building changes the economics in your favour: more differentiating work is now worth building, and the penalty for a modest custom tool is far lower than it was. That’s real, and it’s an advantage worth taking.
But it changes nothing about the risk that matters most. Cheap software built on a misunderstanding of the work is still the wrong software — you just reach it faster and for less money. When building was expensive, its cost forced a pause that caught some of those mistakes. Remove the cost, and nothing forces the pause except judgement. Understanding the work becomes the entire game.
Before a line of code is written
Whether you build or buy, answer these first:
- Is this work differentiating or common? Be honest; most work is common.
- Do we understand the job, or only the current tool? Can we describe the outcome without describing screens?
- Is the operating model underneath this work defined — ownership, hand-offs, what “done” means? Software built on an undefined model just hard-codes the ambiguity.
- If we build, what do we take responsibility for forever — maintenance, security, the knowledge to keep it alive?
Get those answers and the build-versus-buy decision usually makes itself. Skip them and no amount of cheap, fast development will save you from building the wrong thing well.
This question comes directly from When listening to users leads you astray — a redesign that taught me the difference between what users request and what the work requires.