Why AI for BI works for reports, but not platform building

AI makes it look effortless to spin up BI application prototypes and reports, which gives some enterprise leaders the false impression that platform engineering is just as easy.

To illustrate the first point, take a common scenario: a data analyst needs a customer churn breakdown by region for a meeting in two hours. Instead of filing a ticket with the BI team or building the report herself in the company's self-service BI tool, she asks a coding agent to build it. It comes back wired to the data warehouse, filtered and ready before the meeting starts. That's a point solution: a report built to answer one question -- and AI just made that process dramatically faster than either path the analyst previously had.

Over the past 20 years, self-service BI solved a real problem. It lets people who aren't software engineers query the warehouse and build their own reports without waiting on a BI team. But it works inside the tool's boundaries: whatever charts, filters and layouts the BI platform allows. AI removes that boundary. The visuals, interactions and underlying logic are now buildable from scratch, styled and structured however someone wants, no longer constrained by what a BI tool's feature set supports.

That matters because no BI tool ever fully satisfies its users. There's always a report that needs a workaround or a data visualization the platform wasn't designed for. I've seen this complaint in every organization I've been part of, in one form or another.

But there's a downside to freeing users from the old constraints. Self-service BI already led to a proliferation of user-built reports. AI adds another layer on top: allowing more report builders to create their own answers, with different logic and definitions behind visuals that look like they're answering the same question but aren't.

This unchecked expansion is part of the problem, too. It creates exactly the kind of mess a single, standardized system is supposed to prevent: conflicting answers on what looks like the same question. What's often missing is a shared semantic layer that defines what the numbers mean, plus the governance to make existing reports discoverable and retire the ones nobody trusts anymore.

That gap makes the next question feel reasonable: if a coding agent can build the report this fast, why not have it build a full platform, at a fraction of what it costs to buy commercial tools like Tableau or Looker? Companies are already taking this kind of approach in categories with a much bigger lift than BI. Salesforce's price increases have pushed some organizations toward building their own CRM logic. If that's happening with CRM, a BI platform can look like an easier version of the same move.

But that initial estimate only counts the build. It doesn't count what comes after -- and the CRM comparison doesn't hold up as well when you do. A homegrown CRM carries real overhead, too, but it can make sense when the licensing fees for commercial software are expensive enough and heavy customization would be required for your business processes anyway.

A BI platform doesn't have that same business case. It isn't tied to any unique business process, unlike a CRM that might encode a specific sales team's approval chains or territory rules. Querying and visualizing data is largely the same at every company, meaning that building and maintaining a custom BI platform is rarely a differentiator.

Set the resources issue aside. A harder problem remains, no matter who or what builds the BI platform. Creating a single report is genuinely simple now; a coding agent did exactly that in two hours. Productizing a platform that an entire organization can rely on, across current and future use cases, is entirely different work, and AI only makes the first task faster.

Open source BI set out to fix what people didn't like about commercial platforms, promising something simpler, cheaper and more customizable. Superset, built at Airbnb and still maintained as an open source project, later became the foundation for Preset's hosted offering. Metabase took a different route, leaning into usability with a no-code query builder that non-technical people could actually use.

Both addressed real problems: licensing cost, vendor lock-in and customization limits. But neither removed the tradeoff entirely. Superset still requires teams to own hosting and maintenance if they run it themselves. And neither tool matched the breadth of dashboard types, integrations and enterprise access control that the commercial BI platforms had built over the years.

Query performance has to survive an audit months after launch, not just hold up on day one. Someone needs to catch failures before users report them, and there needs to be a roadmap for what the platform will look like a year out, with a feedback loop to drive improvements. That's what productizing requires, and none of it gets easier because a prototype comes together fast.

The upfront cost comparison part of the pitch usually compares a licensing fee against the first working version: the prototype a coding agent produces in an afternoon. That comparison leaves out the more expensive part: turning a prototype into something a wide user base can trust, with proper access control, high availability and an active maintenance plan. That productization phase typically requires far more capital and labor than it took to get the first working version. This gap is exactly where "build our own platform" math quietly stops counting.

None of that makes build the right call. What's changed is that AI makes initial development look so easy that companies stop checking whether buying was actually the problem. Was it too expensive, too complex or insufficient for the need, even after factoring in what the tool could be extended or configured to do?

A BI and analytics leader can run the decision through three questions:

• Core vs. commodity. Is this tied to something core to how the business operates, or is it infrastructure that no company gets paid to run?
• Total cost of ownership. Does the cost model include what it takes to run this as a product long after it ships: security, reliability, monitoring, a lifecycle plan and a feedback loop to make improvements?
• Organizational capability. Is that ongoing work getting treated as the different discipline it actually is, rather than as more coding? That takes its own skills and its own organizational muscle, whether it sits with an internal team or an outside partner.

Point solutions are still fine to build. A single report, a specific app, a one-off analysis with a known shelf life: build it fast and retire it when the question's answered. But the platform is a different decision, and it deserves scrutiny that has nothing to do with how fast the prototype came together.

Sireesha Pulipati is a data and AI engineering leader specializing in scalable data platforms, real-time data pipelines and production-grade AI systems. She is a staff data engineer at Shopify and previously worked at Google, where she led analytics and business intelligence across search and Google Cloud. The views expressed by Pulipati are her own and do not reflect those of her company.