I've been having a version of the same conversation for the past eighteen months, and it keeps ending the same way.
A technology leader, smart, rigorous, usually someone I respect, tells me their team spun up a working knowledge platform prototype in a week using AI coding tools. The interface renders. Data flows. A demo passes. The conclusion they've drawn: this isn't as hard as we thought, so let's build it ourselves.
They're right about the demo. They're wrong about what it proves.
Building software isn't the difficult part anymore. Governing enterprise knowledge over the next decade is.
What a prototype proves is that you can reach 20 percent of the problem quickly. The other 80 percent is where organizations actually get into trouble: governance, integration maintenance, compliance certification, security posture, and keeping AI components current in a market where model deprecation cycles run twelve to eighteen months. That's not a vendor's argument. It's what practitioners who build these systems for a living have documented. For instance, HatchWorks AI put it plainly in their January 2026 build-versus-buy analysis: the initial build is 20 percent of the commitment. Everything after it is the other 80.
IEEE software engineering research adds the long-run math. Maintenance accounts for 60 to 80 percent of a system's total lifetime cost. Cumulative maintenance runs two to four times the original development investment. Development cost is the upfront payment. Maintenance is the mortgage, and there's no payoff date.
The demo doesn't show any of that. It can't. Which is exactly what makes it dangerous.
The open source question
We've had this conversation before.
Twenty years ago, open source promised to fundamentally change enterprise software. Frameworks emerged that made it possible to build CRMs, learning platforms, knowledge management systems, customer portals, and nearly every other category of enterprise application without paying licensing fees.
The argument sounded familiar: “Why buy software when we can build it ourselves?”
Today, AI coding tools have made that argument even more compelling. Instead of spending months building a prototype, teams can generate one in days or weeks. The prototype is undeniably more impressive. The long-term economics, however, haven't changed nearly as much as people think.
So I always ask the same thing: show me a world-class enterprise application that an organization meaningfully replaced by building their own version on open source. One that's still running cleanly five years later, well-maintained, kept current, and that the organization is genuinely glad they built instead of bought.
These examples exist. They're rare. And they share one thing: the capability was genuinely core to what that organization does. Customers chose them because of it. It showed up on the competitive scorecard.
Knowledge infrastructure doesn't pass that test for most organizations. The knowledge itself may be what differentiates the business. The plumbing isn't.
AI didn't change the economics of enterprise software. It simply made forgetting them much easier.
The infinite maintenance problem
Most build analyses compare two numbers: development labor versus license fees. Development labor looks bounded and one-time, and may even look free if engineers have available capacity. License fees look recurring and pushback-worthy. It's a reasonable comparison. It's also missing most of the actual cost.
Cloud infrastructure runs $60,000 to $150,000 annually for a moderately complex enterprise system, even before multi-region deployment and enterprise support are factored in. SOC 2 Type II, the security certification most enterprise procurement teams require before approving a knowledge system, costs $30,000 to $150,000 to establish and $15,000 to $40,000 to renew every year after that. Those figures come from Drata and Thoropass. Accessibility compliance, integration ownership as the technology stack grows, security patching: none of it appears on the initial build estimate. All of it shows up on the annual budget, indefinitely.
These are all costs of operating the infrastructure. AI introduces an entirely new category of cost: keeping the intelligence layer current.
Then there's what I call the LLM Tax. An AI-enabled knowledge infrastructure built today is built to a specification that may be outdated before it reaches production. OpenAI deprecated GPT-3, the Assistants API v1, o1-preview, and GPT-4.5-preview in the past few years alone. Each deprecation is a rework event for the internal team. Every downstream system your platform integrates with updates on its own schedule, with no coordination obligation to you. Your team ends up chasing the ball, keeping up with model changes, API breaks, new compliance requirements, instead of building the thing that actually drives revenue.
That's the real opportunity cost question. Is knowledge infrastructure maintenance the highest-value use of your engineering capacity? For most organizations, it clearly isn't. The answer to that question should drive the decision, and it usually doesn't get asked.
The roadmap you don't have access to
One advantage commercial platforms have is something organizations often underestimate: collective learning.
Our product roadmap is shaped by conversations with thousands of customers: practitioners in regulated industries, technology companies scaling fast, organizations mid-acquisition who need knowledge infrastructure to work under pressure. That collective feedback is what determines what we build, how we prioritize it, and what we anticipate before customers even ask. It's a disciplining force that internal bandwidth can't replicate.
When you build your own system, you lose access to that signal entirely. You're solving today's problem with today's understanding. The commercial platform your competitor uses gets updated continuously, shaped by hundreds of enterprise customers' requirements. Your internal build gets updated when your team has time, which means when nothing higher-priority is competing for that time, and something always is.
There's also a piece of this that rarely shows up in build analyses: the moment you ship, you become your own vendor. When something breaks, when knowledge isn't pulling correctly, when a new compliance requirement surfaces, when a user needs training, that's your engineering queue now, not a vendor's support contract. Support, incident response, feature requests, regression testing after every update. A platform vendor absorbs all of that as a core business function. An internal team absorbs it on top of everything else they were already doing.
The most mature organizations increasingly treat documentation, learning, support content, and AI readiness not as separate systems but as one connected knowledge supply chain. Every maintenance burden you take on in-house slows that chain down.
The M&A question
For any executive reviewing a build decision, here's a test worth adding to the process, and it doesn't require a spreadsheet.
If your organization were acquired tomorrow, or if you were acquiring another company, would your homegrown knowledge infrastructure appear on the asset side of due diligence?
In my experience, the honest answer is almost always no. A homegrown system is undocumented by anyone the acquirer's team trusts, built on dependencies they didn't choose, with institutional knowledge concentrated in people who may or may not survive the transition. The acquirer's options are: maintain something they didn't build, migrate away from it at significant cost, or write it down. None of those outcomes is what the original team had in mind when they chose to build.
MIT's Project NANDA analyzed more than 300 enterprise AI deployments and found that external partnerships, buying from specialized vendors rather than building internally, succeed at roughly twice the rate of internal builds. That gap is consistent with what I see. It reflects how rarely all the conditions for a genuinely defensible build decision are simultaneously true.
When building is actually right
I want to be honest about this, because a sweeping “never build” position would be wrong and most experienced technology leaders would recognize it as such.
There are conditions under which an internal build of knowledge infrastructure is the right call. Three of them need to be simultaneously true. The capability has to be genuinely core to competitive differentiation: customers choose the organization because of it, it appears on the competitive scorecard, and a competitor owning it instead would materially weaken the business. The organization has to have the operational maturity to maintain the system at enterprise security, compliance, and accessibility standards indefinitely, with dedicated resources that don't evaporate when the founding engineers move on. The technology target has to be stable enough to build to, which in a period where LLM APIs deprecate quarterly and AI infrastructure best practices evolve faster than most internal roadmaps can track, is genuinely difficult to satisfy for any AI-enabled knowledge system.
For most organizations evaluating knowledge infrastructure, content distribution, or documentation platforms, none of those conditions are met. The knowledge they carry may differentiate the business. The infrastructure that carries it doesn't.
The full decision framework, including the five questions any leadership team should be able to answer before approving a build, is in the white paper this piece draws from. If you're in the middle of that decision, it's worth working through before the budget is allocated and the engineering team is committed.
Where I land on this, and what we built
I run MadCap Software. We build enterprise knowledge infrastructure. My interest in this argument isn't neutral and I'm not pretending it is.
What I've watched, over many years and many organizations making this decision, is that the ones who get it right make a specific distinction. They own the knowledge: the domain expertise, the learning design, the documentation, the operational experience that helps customers succeed. That's the differentiating capability. That's what competitors can't replicate.
The infrastructure that delivers it is a different category. It's worth buying from people whose entire business is keeping it current, because that work never ends, and it probably shouldn't be yours.
Organizations don't compete on knowledge infrastructure. They compete on the quality of the knowledge flowing through it.
What purpose-built looks like
MadCap Syndicate is the governed content distribution platform we built to solve exactly the problem this article describes. It's not a documentation tool with a distribution layer bolted on. It's built from the ground up to be the central hub through which enterprise knowledge flows: structured, governed, AI-ready, and compliant.
The specific problems it addresses are the ones that sink internal builds. Multi-format delivery to any channel without requiring engineering intervention each time. Role-based access controls that meet enterprise security requirements without custom development. SOC 2 Type II compliance maintained by our team, not yours. AI-ready content architecture that doesn't require reworking your knowledge base every time a model deprecates. Accessibility standards built into the delivery layer, not retrofitted after the fact.
When a new customer brings Syndicate into their stack as part of a complete knowledge supply chain, from technical documentation and learning design through to governed distribution, they're not just buying software. They're buying out of the permanent obligation to staff, maintain, and evolve a piece of infrastructure that isn't core to what makes their business competitive. We carry that obligation instead, and we carry it across thousands of customers whose collective requirements drive what we build next.
That's the compounding advantage of a platform with a real customer base behind it. Your internal build doesn't have that.
Build what only you can build. Buy the rest.
A detailed cost framework for enterprise knowledge infrastructure builds, including the full hidden cost analysis, the M&A evaluation lens, and the conditions under which building genuinely is the right answer, is available in “The Infinite Maintenance Problem: What Enterprise Leaders Get Wrong About Building AI Content Infrastructure,” independent research by Dominic Tavassoli, sponsored by MadCap Software.
If you're evaluating a content infrastructure decision and want to see how Syndicate addresses it in practice, schedule a conversation with our team.
About the author
Anthony Olivier is CEO of MadCap Software, provider of enterprise AI knowledge infrastructure. MadCap's portfolio spans the full knowledge supply chain: from technical documentation and L&D authoring with Flare, IXIA CCMS, and MadCap Create, to governed AI-ready content distribution through MadCap Syndicate.
