Build vs. Buy: Why the Math Changed Less Than You Think

A version of this conversation is happening in almost every IT leadership meeting I sit in lately. The capabilities are all available now. Azure and AWS rent you infinite infrastructure by the minute. The foundation models are an API call away. And with AI coding assistants, a small team can produce working software faster than most of us thought possible even two years ago. So the question lands naturally: with all of that, why would we pay for SaaS when we could just build it ourselves?

It is a fair question, and a more reasonable one than it used to be. I want to take the build case seriously before I tell you where I land, because the build case is real.

What actually got cheaper

The cost of producing software has dropped, and it is not hype to say so. GitHub's own research found developers completed tasks roughly 55% faster with an AI assistant in the loop. The first working version of almost anything now arrives in days. Scaffolding, glue code, the boilerplate that used to eat a sprint, all of it compresses toward zero. For a capability that is genuinely core to your business, that is a real argument for building. If the thing you would build is your actual product, the thing customers pay you for and no vendor can sell you, then build it. You should own your differentiation.

There are other honest reasons to build. Sometimes the workflow is so specific that no product fits without contortions. Sometimes you already run a mature platform team that ships and operates internal software well, and adding one more service is a marginal cost rather than a new muscle. Those situations are real, and in them building can be the right call.

So I am not here to tell you building never makes sense. I am here to tell you that the thing AI made cheap is not the thing that determines whether build-vs-buy goes well.

What did not get cheaper

AI compressed the cost of the first 80%. It did almost nothing to the last 20%, and in document-heavy work the last 20% is the whole game.

Think about what a real document operation actually requires. Extraction that holds its accuracy across millions of documents and hundreds of formats, not just the clean samples in the demo. Exception handling for the cases the model is unsure about. A human-in-the-loop design that routes low-confidence results to a person and lets high-confidence results flow through. An audit trail that satisfies a regulator. Drift monitoring for when the underlying model changes underneath you, because it will. Single-tenant data isolation. SOC 2, HIPAA, FedRAMP, depending on who you serve. None of that is a prompt. None of it is the part the AI writes for you. It is the part you inherit the moment you decide to own the system.

This is why large build efforts have such a poor track record, and why the track record has not improved much despite better tools. The Standish Group's long-running research on technology projects has found for years that large projects succeed less than 10% of the time, with the majority landing late, over budget, or short of what they set out to do. Faster code generation does not fix that, because the thing that sinks these projects was never typing speed. It was scope, integration, compliance, and the slow realization that the demo and the system are different animals.

The cost you sign up for is the cost of owning it

Here is the number I wish every build-vs-buy deck included. Across decades of software engineering research, maintenance accounts for roughly 60 to 80% of the total lifetime cost of a system. The build is the small part. Owning it is the big part.

Writing the code was never the expensive part, and now it is cheaper still. Everything wrapped around the code is what costs money, and AI did not touch any of it. You need infrastructure, and someone to architect it so it stays up under real load. You need DevOps expertise to deploy, monitor, patch, and scale it. You need support staff for the day a user cannot find a document an hour before a deadline. You need a standing budget for bug fixes and the steady drip of improvements every production system demands the moment real people start depending on it. Cheaper code does not make any of that cheaper. It just gets you to the part where the real bill starts sooner.

So when you choose build, you are not buying a feature. You are signing up to be a software company for a function that is not your product. You own the on-call rotation when extraction quality drifts at 2 a.m. before a filing deadline. You own the model-deprecation treadmill every time a provider sunsets the version you built on. You own the compliance renewals and the penetration tests. You own the risk that the one engineer who understood the pipeline takes another job. In regulated industries especially, that ongoing burden does not scale down. It scales up, right when you are least able to absorb it.

This is the same trap I wrote about with RPA. It is easy to stand something up. The expensive part is keeping it alive and correct as the world around it changes. AI moved the easy part. It left the expensive part exactly where it was.

The cost that never shows up in the spreadsheet

There is a part of this decision that no TCO model captures, and I think it matters more than the numbers. When you own the solution, you own the uptime. Not in the abstract. At 2 a.m., when a business-critical system goes down and the people who depend on it are blocked, that is your problem and your team's problem, and there is no vendor to call.

Ask yourself the honest version of the question. When you lay your head on the pillow at night, do you want to be the person responsible for keeping that system running? Do you want your best engineers carrying a pager for a function that is not your product, instead of building the things only your company can build? For a capability that is truly your differentiator, that pressure is the cost of doing business and you take it on gladly. For document processing plumbing, it is pressure you are choosing to absorb for no strategic return. Owning the outage is a real liability, and it belongs on the build side of the ledger even though it never appears there.

The decision is really about where your engineering compounds

I think the honest way to frame build-vs-buy is not "can we build it." With today's tools, you almost always can. The real question is whether the effort you pour in compounds into durable advantage or just into keeping the lights on.

Engineering spent on your actual differentiator compounds. Engineering spent rebuilding extraction accuracy, audit trails, and compliance plumbing that a platform already solved does not. It is a tax you pay every quarter to maintain parity with something you could have bought outright. And the failure mode is quiet. The build works in the demo, ships to production, and slowly turns into the system nobody wants to touch and nobody can replace.

This is the reason I land on buy for document work, and land there firmly. Not because building is impossible, but because the math favors owning your differentiation and renting the floor underneath it. AI compounds on a platform. It fragments on a patchwork.

The good news is that the binary framing hides a better option. The instinct to build usually comes from a real place: teams want a solution shaped exactly to their process, not a rigid product they have to bend their operation around. That instinct is right. The mistake is assuming the only way to get it is to build the whole thing from the ground up and own everything underneath.

The better answer is a platform you can shape to fit, extensible at every level. No-code for the business users who need to adjust a workflow without filing a ticket. Low-code for the configurators who tailor it to a specific process. Pro-code for your developers when a requirement is genuinely yours and nothing off the shelf will do. That is how we built KnowledgeLake, and it was a deliberate choice. You get the security, compliance, and accuracy floor without rebuilding it, you get the infrastructure, the uptime, and the support as someone else's job to lose sleep over, and you still get exactly what you want, because you can build your own IP right on top. That is not build vs. buy. It is buying the foundation so your team can build only the part that is actually yours, which for an enterprise modernizing a fragmented stack is almost always the right answer.

So when your team makes the case to build, and a good team will, ask the second question. Not "can we build the demo," but "do we want to own this system for the next ten years, including the parts AI did not write for us." If the answer is yes because it is your core product, build it well. If the answer is no, you already know what to do. If you are working through that decision for your document stack, I am always glad to compare notes.