The Question Most Companies Ask Backwards
I've spent the better part of a decade on the wrong end of this question.
For seven years at my previous company, building internal tools was my job. Not as a side project, not as a quarterly initiative — it was the thing I did every day, along with the harder, quieter work of making sure people actually used what I built. Now I'm the CEO of AgentUI, where I help other companies make this exact decision. So when someone asks me whether they should build or buy, I'm not reaching for a framework I read somewhere. I'm reaching for scar tissue.
Here's the short version of what I learned: most companies ask the question backwards. They start by asking "can we buy this?" when the better starting question is "is this process unique to us?" Those are not the same question, and confusing them costs years.
Let me explain.
The Default Everyone Gets Wrong
The conventional wisdom is sensible enough on paper: try off-the-shelf first, and only build if nothing fits. We followed that rule religiously. We always tried to buy before we built.
The problem is what "trying" actually looked like in practice. For one critical part of our operation, we spent years — not weeks, years — trying to make purchased software work. We ran two different tools across that period. Both failed. And they failed for the same reason every time: they required us to adapt our operations to their software, instead of adapting the software to our operations.
That sentence is the whole debate in miniature. When you buy off-the-shelf software for a process that's genuinely unique to your business, you're not buying a solution. You're buying a renovation project for your entire way of working, and the renovation never quite finishes. Every workaround, every "we'll just do this part in a spreadsheet on the side," every training session explaining why the tool doesn't do the obvious thing — that's the cost of forcing your business to fit someone else's assumptions.
The thing nobody tells you is that this cost is invisible on the invoice. The software has a price tag. The years of operational friction don't.
A Case Study: The Sales Tool That Opened Up the World
Let me make this concrete, because abstractions are easy to nod along to and hard to act on.
One of the biggest tools I ever built was for our sales reps. Before it existed, creating a quotation was a manual ordeal. A rep had to stitch together a handful of Excel files, hunt down inventory data that may or may not be current, and dig up the technical information — the spec sheets, the PDFs, the approach documentation — from wherever it happened to live. It was slow, error-prone, and it depended entirely on the individual rep knowing where everything was.
So we built a tool where a rep could log in, view live inventory, and create a quotation on demand. The unlock wasn't just speed. It was that every piece of technical information lived in one place. Click on a product, and you saw everything: the specs, the documentation, the PDFs, the approach. And then — this was the part that mattered most — you could share the whole thing with a client in a single click.
That tool did something I didn't fully anticipate when I started building it. It let us win clients from all over the world that we'd never been able to reach before. When a prospect on another continent can get a complete, professional, technically detailed quotation in minutes instead of days, the geography stops mattering. The tool didn't just make us faster. It expanded the size of the market we could credibly serve.
No off-the-shelf product was ever going to do that, because no off-the-shelf product understood our inventory, our technical documentation, and our sales motion the way we did. We tried. Remember those two tools and those wasted years? This is what they were trying and failing to replace.
So When Should You Buy?
If you've read this far thinking I'm an "always build it yourself" zealot, let me correct that immediately. I am not.
I would never build a CRM. We buy our CRM, full stop, and I'd advise almost everyone to do the same.
Here's the distinction. A CRM needs to integrate with your email and a dozen other tools. It's a genuinely complex, mature category, and the existing products are robust precisely because thousands of companies have hammered on them for years. There is no unique advantage to be gained by rolling your own. You'd spend enormous effort to arrive, at best, at something slightly worse than what you could have bought on day one.
That's the test, and it's simpler than most build-vs-buy frameworks make it:
- Buy when the problem is universal. If a hundred other companies have the same need you do, someone has already built a better version than you will, and they've already integrated it with everything. CRM, email, accounting, payroll — these are solved. Don't reinvent them.
- Build when the process is unique to you. When you have a workflow that's specific to how your company runs — the way we created technical quotations, for instance — that's exactly the moment building makes sense. There's no product that fits, because the process only exists inside your walls.
The deciding question is never "does software exist for this?" It's "is what I do here different enough that no generic tool can capture it?" If yes, build. If no, buy and move on with your life.
What AI Actually Changed
For most of my career, that decision tree came with a brutal asterisk: even when building was clearly the right call, it was expensive. You needed developers. You needed time. The build option was correct in theory and often unaffordable in practice, which is why so many companies defaulted to buying tools that didn't fit — and then spent years suffering for it, like we did.
AI has collapsed that asterisk, and this is the part I find genuinely exciting.
The old world forced you to adapt your entire operation to fit the software. The new world lets you build software that adapts to your business. That reversal is the whole game. Every business is unique, and for the first time you can have a system that digitizes your operations and the specific way you run your company — without an engineering army to do it.
This is exactly what we're building at AgentUI. The idea is that you can build whatever internal tool you need with AI, instead of hiring a developer and waiting months. To be clear: developers absolutely still have a job. I'd use a developer for customer-facing products in a heartbeat — the things your customers touch deserve that level of craft and care. But for internal tools? In most cases, you don't need one anymore. You need AI and a tool that lets you build.
This shifts the build-vs-buy math in a way that's easy to underestimate. When building was costly, "buy and bend your operations" was often the rational choice even when it hurt. Now that building is cheap and fast, the calculus tilts hard toward building anything that's genuinely yours.
The Two Objections I Hear Most
Whenever I make this case, two concerns come up almost every time. They're fair, and they deserve straight answers.
"What about security?"
This is the big one. Companies worry about information leaking, about the wrong people accessing data, about getting hacked or losing information. It's a legitimate fear — building your own tools historically meant owning your own security headaches. This is something we solve directly at AgentUI with managed infrastructure, so that whatever you build is secure and safe by default. You shouldn't have to become a security expert to build an internal tool, and you shouldn't have to choose between "fits our business" and "won't get us breached."
"Won't we be stuck maintaining it forever?"
This is the maintenance and technical-debt fear, and it's the one that quietly kills a lot of good build decisions. The assumption is that building means signing up for an eternity of upkeep. But here's the thing people miss: there comes a point where you can simply stop building. The tool does its job, and you walk away from it. And the genuinely hard part — maintaining the infrastructure underneath, the part that actually generates the dread — is exactly what we handle on the back end, so you're not babysitting every piece of it. Build it, finish it, move on.
The Contrarian Take: Stop Trying to Build the Cathedral
Here's the opinion I'll plant my flag on, and it's the thing I think most people get wrong even after they've decided to build.
Don't try to build a huge system from scratch. It's a bad idea, almost always.
The instinct, once a company gets excited about building its own software, is to go enormous — to architect some sweeping internal platform that will run the whole business. That's how build projects die. They collapse under their own ambition before they ever deliver value.
The far better move is to digitize the processes you already do manually — the ones living in Excel right now, the ones that are unique to your company. That's it. Find the spreadsheet your team dreads, the manual stitching-together that eats hours every week, the thing only your company does in only your particular way. Build that. It's small, it's concrete, it has an obvious payoff, and it's exactly the kind of thing no off-the-shelf tool will ever handle well.
Start with the painful spreadsheet, not the grand vision. The cathedral can wait. The quotation tool that opened up the world for us didn't start as a moonshot — it started as "this manual process is killing us, let's fix it."
The Bottom Line
Buy the universal stuff. Build the stuff that's truly yours. Don't bend your operations to fit software that was never designed for you — for years we made that mistake, and the bill came due in lost time and lost opportunity. And whatever you build, start small, start with the manual process you already understand, and let the tool grow from there.
For most of my career, that advice came with the caveat that building was a luxury. It isn't anymore. The thing that used to require developers and quarters of work can now be built by the people who actually understand the process — which is to say, by you.
That's the real shift. The question was never just build versus buy. It was whether you could afford to have software that fits the way you actually work. Now you can.