Every growing company has this conversation. The current tool doesn't fit. Someone proposes building something custom. Someone else pulls up pricing for three alternatives. The discussion turns into a feature comparison.
For years the sensible default was clear: buy. Building was slow, expensive, and left you owning code nobody wanted to maintain. Custom tooling made sense for a handful of companies with engineering to spare.
That default is no longer obviously right. The cost of building has dropped sharply — AI has collapsed the time it takes to produce working internal software, and more importantly the time it takes to change it once it exists. Things that would have been a six-month project with a dedicated team are now realistic for a small company.
Which means the constraint has moved. The question is no longer can we build this. It's do we know what we should be building — and that question is much harder to answer from the inside.
The new failure mode
When building was expensive, the cost of building the wrong thing was obvious and painful enough that it forced deliberation. Now you can build the wrong thing quickly and cheaply, which means you can also build it without noticing.
The most common version: a company rebuilds its current mess in a new interface. The existing tool feels broken because three people use the same field for different purposes, the workflow reflects a process that changed a year ago, and half the team maintains a parallel spreadsheet. Build a custom system on top of that, and within six months it feels exactly as broken — because the problem was never the tool.
A second version: the spec becomes a feature list collected from whoever asked loudest. Each feature is individually reasonable. Together they describe no coherent process, and nobody can say what the system is actually for.
A third: the thing gets built well and nobody owns it. It works until the person who commissioned it moves on, and then it quietly decays.
All three are avoidable. None of them are usually visible to the people inside the company, because the people inside the company are the ones who normalised the current way of working.
What outside guidance actually adds
The value of bringing someone in isn't technical. With AI, the building is the part you least need help with. The value is in the questions asked before anything gets built — and in the fact that they're asked by someone with no history to defend.
What is the process, really? Not what the process document says. What actually happens, including the exceptions and the workarounds. If this can't be described precisely, no tool — bought or built — will fix it.
Which part of this is genuinely yours? Most of what a company does operationally is standard work that thousands of companies do the same way. Some small part of it is how you actually compete. Building the first category is a waste. Building the second is where the advantage is. Telling them apart is harder than it sounds from the inside, because the standard parts feel distinctive when you've always done them your way.
What would we have to stop doing? A new system that adds to existing habits without replacing anything doesn't get adopted. The design has to include what goes away.
Who owns it in two years, by name? If the answer is vague, or if it's the founder, nobody owns it.
How will we know it worked? Decided before the build, not after. Otherwise the measure of success becomes "it shipped."
The shape that usually works
Buy the commodity. Email, accounting, calendars, standard CRM functions — there's no advantage in owning these and real cost in maintaining them.
Build the part that's genuinely specific to how you operate: the reporting layer that reflects how you actually measure things, the workflow that encodes the way you serve clients, the data model that matches your business rather than a vendor's assumptions. These are the places where off-the-shelf tools force you to work the vendor's way, and where building now costs far less than it used to.
And build it from a defined process, not from a feature list. The sequence matters more than the technology: diagnose how the work actually flows, design what it should look like, then build the thing that supports it. Skipping to the build is what produces expensive software that nobody uses.
The real opportunity
The companies that will get the most out of this shift aren't the ones that build the most. They're the ones that know precisely what's worth building.
AI made execution cheap. It didn't make judgment cheap. If anything, it raised the value of the work that happens before the first line of code — because now you can get something wrong at a speed that used to be impossible.