The fusionSpan Blog

From Domo to Claude: Putting the Intelligence Back in Business Intelligence

By Manav Kher |September 17, 2026

For over three years, Domo was our business intelligence tool, and it was generally a strong one for us. We built our finance, project delivery, and operations dashboards on it, covering IT, finance, and HR. It gave us an org-wide view of our data, had excellent visualization capabilities, and made it fairly easy to build new dashboards.

The downside is that even though the dashboards themselves are easy to build, getting to that point of actual development takes a team: a business analyst to gather requirements, a data engineer to set up the data load (ETL), and a BI developer to build the actual dashboard. Finding a business analyst who understands requirements at the organizational level, across departments from delivery to operations, is hard.

The bigger downside is cost. Getting started is inexpensive, but the credit-based usage model made our spending hard to predict.

Then Claude entered the picture. As our team started using Claude in their day-to-day work, they found it could create excellent data visualizations too. Where we once needed an entire team to build a dashboard, Claude can access the data (via MCP), link data across systems, reason over it, and build an intelligent dashboard. It put the “intelligence” back into our business dashboards.

Data Access

That data access is the key piece. Claude can connect to any system that provides an MCP server, and most of the tools we already use do: Salesforce, Asana, Jira, Confluence. Once those servers are enabled, Claude can pull data from all of them, link it together, and reason over it directly.

Team Effort

This has also changed who can actually build a dashboard. Where we once needed a specialized BI developer for every request, our recruiters now build their own recruiting dashboards, and HR builds its own HR dashboards, without pulling in anyone else on the team.

Cost

The cost beyond our existing Anthropic subscription (which we have regardless) is minimal. This has let our IT team build dashboards the entire organization actually uses. Because we host them ourselves, we set granular permissions on who can access what.

External Access

Sharing no longer carries a per-view cost, so we’ve also turned our client project reports into dashboards clients can access directly.

Instead of waiting on a weekly progress report from their project manager, clients now get real-time insight into how their project is progressing, along with visibility into budget and time to completion.

With our previous setup, dashboards were tied to the vendor’s platform, which limited our flexibility with access controls. Now we control who sees what, including clients.

Deployment

One of the best parts of building our own dashboards is that we host everything without any infrastructure of our own.

Instead of running servers, we deploy each dashboard’s code to Cloudflare Workers, a serverless platform that runs on Cloudflare’s global network close to whoever is using it. The code runs only when someone opens a page or the dashboard requests data, and it starts almost instantly.

Cloudflare also provides the pieces around the app: employee sign-in through Cloudflare Access, encrypted storage for credentials, and a built-in cache. There is no extra infrastructure to set up or maintain.

This pay-per-use model is what keeps costs low. Workers bills by usage, not by server or by user, and a single $5-a-month plan includes 10 million requests (at the time of writing), far more than internal dashboards need. With no idle servers, no bandwidth fees, and no separate login system, hosting costs stay low.

Each dashboard is one packaged web application, and that package is what we deploy. It contains:

The screens people see: the pages, charts and tables of the dashboard.
The behind-the-scenes logic: the code that pulls data from our internal systems.

Passwords and API keys aren’t part of the package. They’re stored separately in Cloudflare as encrypted secrets, and the app reads them only while it runs.

Claude writes the code. We then run a single deploy command, which uploads the package to Cloudflare, and the dashboard is live on its fusionspan.com address within seconds. Cloudflare provides everything else.

Other Advantages

Iteration speed: Changing a dashboard used to mean going back to a BI developer and waiting. Now you ask, “add a filter for region” or “show this as a trend instead,” and see it in minutes instead of days.
No pipeline required for ad hoc questions: Traditional BI typically needs the data modeled and piped in ahead of time. Claude can reach into systems live via MCP and combine them on the fly, so a one-off question doesn’t require someone to build a pipeline first.
Narrative, not just charts: Claude can explain what’s driving a trend or flag something that looks off, alongside the visualization. That’s closer to having an analyst look at the data with you.
One-off dashboards become worth building: With no development cost per dashboard, it’s reasonable to build something for a single meeting or analysis. Before, that math never worked, so those dashboards never got made.
You own the output: The dashboards are HTML you host yourself (on Cloudflare, in our case), not something rendered inside a vendor’s platform. That has made sharing so much easier.

Tradeoffs

This approach isn’t hands-off. Someone still has to validate that the numbers are right, especially for dashboards that leadership or clients rely on, and because we own the code, we also own the maintenance when a source system changes. For client-facing dashboards, we treat access control and data review as part of the build, not an afterthought.

Domo is what we used, but the lesson applies to any major BI platform: when a capable AI can reach your data and build the dashboard in minutes, the case for a heavyweight BI stack gets much harder to make.

Manav Kher

The official gear-head of fusionSpan. Manav has over 14 years of enterprise software development experience. Previously he spent 7 years in various lead development and architect roles at the National Cancer Institute (NCI). Notably, he contributed to the architecture and development of some of the core components of the caBIG infrastructure, for which he received the NCI caBIG Outstanding Achievement Award.