In conversations about enterprise analytics, I keep hearing some version of the same question: AI makes it easier to build our own software, so why would we buy it?
It's a fair question, but easier development doesn't establish the business case for owning the product. Focused software companies can move with less organizational friction, spread their investment across customers, and keep improving while an enterprise works through approvals.
I expect that advantage to compound. AI will also make more specialized SaaS businesses viable, expanding the options even for niche use cases. Internal expertise is better spent applying and enabling AI across the business than recreating products that already exist.
My recommendation is simple: buy a foundation and adapt it to your business. Any internal build should have to justify both the investment and the responsibility that comes with it.
Enterprises can't compete with the 100x developer
The software companies an enterprise is trying to replicate have access to AI too. What separates them is how much of that speed actually reaches the finished product.
Imagine AI makes an enterprise development team 10x faster. That's substantial progress, but the organization around the team hasn't changed. Priorities still compete across departments, and funding, procurement, and multiple approvals still stand between an idea and the people who need it.
Now imagine a focused software company gets a 100x improvement. With far less friction, its team can move from a customer problem to an experiment, a release, and real feedback. Its product can go through several cycles of development, testing, release, and customer feedback before the enterprise clears its first internal approval gate.
The exact multipliers will vary. What matters is how quickly each organization turns better tools into a better product.
The advantage extends to cost. AI lets a focused software team develop, manage, and deploy software with significantly fewer resources. The enterprise gets the same tools, but its staffing, coordination, and approval overhead don't go away.
And the gap grows with every cycle. The software company ships, learns, and improves, and each round strengthens both the product and the process used to build it. The next cycle starts from a better position than the last.
Buying goes through approvals too, of course. Procurement, security reviews, and AI governance assessments all take time. The difference is that the enterprise clears those gates once, and the vendor keeps shipping behind them. An internal build has to compete for funding, priority, and approval release after release. Even in the longest enterprise buying cycles, a focused vendor still far outpaces the internal team on both innovation and economics.
In the agentic AI era, this compounding becomes exponential rather than linear. Better tools accelerate development, faster experimentation improves how those tools are used, and as agents take on more of the work, each improvement feeds the next.
The result is that the gap between internally built software and capable commercial products will become wider than ever, and it will keep widening. A promising prototype today may find itself chasing a much stronger, less expensive product by the time it reaches production.
Five arguments for building that AI weakens
Building can feel like the obvious next step when leadership wants visible progress and a team has the tools to deliver it. I've often heard the case framed around the people already on the payroll: we have engineers and data scientists, and they want to do this work.
Those familiar reasons for building deserve another look, because AI weakens each of them.
- We already have engineers. Then put them to work on AI enablement: connecting data, integrating software, adapting it to the business, and helping teams use it effectively. On top of that comes the growing work of cybersecurity, model governance controls, and model observability. Existing talent strengthens your ability to adopt and apply good software, but it doesn't automatically justify rebuilding it.
- Building will be cheaper. AI makes development cheaper for the vendor too. A focused vendor can build and maintain the product with fewer resources and then spread that investment across many customers. The enterprise, meanwhile, carries the full investment for its own use, plus its internal overhead. A cheap first version doesn't mean cheaper ownership over time.
- We need control over our business rules and workflows. A foundation that supports customization and targeted extensions preserves that control without requiring you to own the entire product. Owning all the code means owning the maintenance, the security, and the pressure to keep pace as AI advances.
- A vendor is just a wrapper around the model. A product that solves multiple use cases and delivers measurable value isn't a wrapper. Agent orchestration, context management, metric definitions, evaluation, accuracy controls, and governance are hard problems, and they get harder as the use cases multiply. The model is only one component. The real work is making it reliable, consistent, and trusted across an enterprise, and that's exactly the work an internal team underestimates when the first prototype looks impressive.
- Our use case is too niche. Niche doesn't mean unique. If dozens of companies share the problem, there's a market for a focused vendor, and AI makes those smaller markets viable for small software teams. Those teams keep the same speed and cost advantages over an internal team, so a specialized problem doesn't automatically require an internally owned product.
There's a useful parallel in YouTube, which made room for creators serving narrow, passionate audiences. Shared distribution and cheaper creation tools made more niches viable, and AI will do something similar for enterprise software. A small team can now build a business around a problem shared by a relatively small number of customers, without needing a billion-dollar market.
That points toward a proliferation of specialized SaaS. The same AI advances that make an internal build look attractive also make a focused commercial alternative faster, cheaper, and more viable.
Buy the foundation and customize for the business
The default, then, should be to buy a maintained foundation and adapt it to the business. The enterprise brings its data, metric definitions, operating context, and specialized capabilities. It doesn't need to recreate the underlying product to make the technology useful.
Buying well still takes discipline. Own your data, your metric definitions, and your business context, and make sure they stay portable. Favor foundations with clear extension points over closed systems. That protects the enterprise if a vendor changes direction, and it keeps the investment in the business rather than in the code.
This approach mirrors BCG's buy-and-build framework, which combines commercial software with selective internal development.
A custom build can still make sense for a one-off problem that available software can't solve, even with customization. But that exception doesn't justify making internal development the default or taking on responsibility for an entire software product.
What this means for agentic analytics
At Enlighten, our team built Aria, which focuses on analytics for quick-service restaurants, and the build-versus-buy question comes up regularly.
GCP, AWS, Snowflake, Databricks, and Power BI all belong in that evaluation. The comparison should account for both the business work each can deliver and the additional development and maintenance the enterprise would take on. I'll explore those comparisons separately in the future.
The point here is the decision that comes first: whether building and maintaining your own software is necessary to achieve the business outcome.
For most enterprises, the answer is no. Build only where the capability is truly proprietary and a competitive advantage in its own right. For everything else, buy the foundation and put your internal expertise into making AI work for the business.