I have been frustrated with the build-vs-buy debate for a while, and I want to explain why before I add to it.
Nearly everything written on the topic comes from vendors, and the arguments are weak. You’ll have to maintain it. Requirements will change. You’ll need governance controls later. Somebody will leave and take the knowledge with them. All of this is true and none of it is interesting, because it is true of every piece of software anyone has ever built. When a vendor’s best argument against building is that software needs maintenance, the reader concludes, correctly, that the vendor doesn’t have much else to offer.
I am a vendor too. But I think the conclusion those pieces reach is right, and I want to give you the actual reasons, because you are being or going to be asked this question and the answers currently aren’t enough for good decision making.
Yes, you can build it
Start with what IT is telling you, because it’s true. An average engineer with a current model and today’s APIs can build an invoice extractor in a week. It will work. If you have a process that is fully understood, stable, and specific to you, building your own automation is a good choice, and I’d make it too. It’s really not that deep. Everyone can build now. Fable and Astra are Marvels.
The problems are in
Process
(Not) knowing what’s possible
Skill & Talent
Economics
Process, Process, Process
On nearly every deployment, the process gets mapped with finance leadership, everyone agrees the map is complete, and a few days in the clerks who actually do the matching send us dozens of cases that aren’t on it. This customer always short-pays by the freight amount and that’s fine. Those two accounts are one entity since the merger. None of it was ever written down. Just another Tuesday, oh well.
It’s easy to discount as “requirements change.” But realistically good Software has to define the process and manage the change (like vertical vendors do: Harvey, Lio, Hubspot in the past) or make it easy to learn and get input from the actual process. Celonis made it a Billion Dollar business to “mine” the real process, it’s a case by case decision based on organisation needs. What will break always is building software on a poorly understood process.
What is “good”
I care about this the most as an engineer and tech-optimist.
When your engineer scopes the build, they need a definition of “good.” Where does it come from? From what the team currently expects, which is anchored on whatever the legacy vendor delivered, which was built on old technology. They all have now relabelled their product as agentic. I’m sorry but you’re being deceived. That’s also why pilots are disappointing. If I got a PT Cruiser promoted as a F35 I would be pissed too.
The result is that nobody in the room knows what “good” actually looks like today. We still get asked whether our platform can handle handwritten documents. That has been a solved problem for two years. Nobody asks whether it can process every document, because it hasn’t occurred to them that this is on offer. Ceiling in our case: In finance operations, the best available systems process every incoming document, in every process, with no human touching the routine cases at all. People are involved only where the process itself says a person decides. For example, whether to dispute an invoice or to eat it to protect a vendor relationship; That’s is a decision not made by AI. Strategic decision making. But everything else is up for grabs.
I want to be very clear about this part. This technology is a marvel. What it can do changes month to month, and if following it and experimenting with it is not your top priority, you do not know what is possible. There’s no way to know. For me, that is the most frustrating part of this whole debate: watching people build to a target that was already obsolete when they set it, and declare victory when they hit it. The bar is usually far, far too low.
The hard part is invisible from the outside
What goes into a finance agent looks simple: an invoice, a statement, a remittance. What comes out looks simple: a match, a flag, an approval. Self built version and ours look identical from the outside. Everything that matters is hidden under the hood, and getting it right has taken us one technical invention after another.
One example, because CFOs are allowed to enjoy a piece of technology too. The hardest problem in running an agent is not the model. In the right setting they solve Million Dollar Math problems. It’s what the agent is allowed to see and do. The usual answer is to give it a short list of pre-built actions, one per task someone anticipated. That works until the first situation nobody anticipated, and in finance those are the rule.
We gave each agent gets its own computer instead. On it, your entire finance operation shows up the way documents show up on a laptop: every open item, every invoice, every comment someone left is a file it can open and read. That way it can act tasks that weren’t built in before and instead just use its own intelligence do the job.
It sounds obvious once said. It took us most of a year to build. (The technical version is in Agents need their own UI.) That is one invention. There are others, in how agents learn a process from the people running it and in how an analyst, a controller and an auditor each work with the same agent differently.
This is hard to plan for without dozens of tries where the easy approach failed.
Tech companies buy technology too
There’s an assumption in this debate that buying is what non-technical companies do. It isn’t. We buy Temporal for workflow orchestration, Stripe for payments, Clerk for authentication, Aikido for security scanning. We could build any of these but each of them solves a part of our stack that we simply need to work, it works, and it costs a fraction of what building it would.
The reason to buy isn’t that you can’t build. It’s that a company that has decided to do one thing accumulates three things you can’t: the best people in that specific problem, a position at the state of the art that they have to hold to survive, and the distilled experience of every company with that problem they’ve ever worked with.
Airbus and Boeing don’t build seats. Recaro does, because Recaro decided to build the best seats and nothing else, and every airline’s cabin teaches them something the next airline benefits from. Airbus could build a seat. It would be worse and cost more, and nobody at Airbus finds this embarrassing.
The economics
Running an agent system in production has a large fixed cost and a small marginal one. The infrastructure, the sandbox, the review tooling, the monitoring, the people who keep it at the state of the art: these cost about the same whether one company uses them or a hundred. A vendor spreads that across every customer. In-house build carries all of it for one. It does not matter how cheap the initial build was; the per-company cost of running it is structurally higher than the vendor’s, always and forever.
On talent, plainly
I’ll say this directly because being polite here is useless. I know more about running AI agents, connecting data to them, and making them improve themselves than almost anyone, and my team knows more about the trap doors in finance processes than almost anyone, because that is all we do. Your IT does not have this. That’s not a comment on their ability. It’s the same reason I’m not designing handbags or playing in the NFL: the people at the frontier of any specific thing are a small group, they’re concentrated in a few dozen companies, and they’re expensive. A non-tech IT department was not built to compete for them and shouldn’t be. There’s exceptions where non-tech companies spin-off their internal technology. If this is your ambition: Amazing, build away!
When you should build anyway
Build if the process is proprietary and gives you a competitive edge that a vendor would necessarily share with your competitors. Build if it’s stable, fully documented, and everyone involved has been in the room. Build if you have people whose actual job it is, with a multi-year mandate, not a side project. Build if the ceiling really is where the legacy system left it.
In finance operations, these conditions are rare. Deductions, cash application, freight audit, reconciliation: none of them are proprietary, all of them have a long tail, and the ceiling is far above where anyone’s expectations currently sit.
So when your engineer says “we could just build this,” they’re right, and it’s the wrong question. Airbus could build seats. The question is whether you want to be in the business of building it: not once, but every month, for years, against people who do nothing else and see a hundred companies’ worth of edge cases before you’ve seen your own. If the answer is yes, you’ve just started a software company inside your finance department. That can be the right call. Just make it on purpose.