How We Built a Live AI Data Dashboard With Claude Code

The Question We Used Throughout the Session

We posed a simple business question to the AI: What were the top five product categories by revenue in 2018?

It sounds simple. The system still has to join the right tables, translate the categories, apply the correct date range, and calculate revenue from the right fields.

We used the Olist Brazilian e-commerce dataset, which contains roughly 100,000 orders across eight connected tables. That made it a useful test case. The answer had to come from the records, not from recognizing a familiar dataset name.

The Ideas Behind the Build

Before opening the tools, I briefly covered three ideas.

Grounding gives the model access to the necessary source before it answers. MCP, or Model Context Protocol, gives compatible AI tools a standard way to use that connection. Build time versus runtime helps decide where AI should sit in the finished product.

Those concepts shaped the session, but the workshop itself centered on two build parts: creating the grounded brain and turning it into a dashboard.

Build Part 1: Creating the Grounded Brain

I started by asking ChatGPT for the top five categories without giving it the dataset. It confidently gave me report-ready-looking output with the category names, revenue numbers, a total, and a chart.

Then we cross-checked it.

One category did not exist in the data. The five category values added up to more than the total shown above them. The response also described the full year, even though the available 2018 records stopped in October.

The answer looked polished, but the model had no reliable path to the source.

Giving the Model the Files

As the next step, I uploaded the CSV files directly to ChatGPT and asked the same question again. This time, the model inspected the tables, used the category translation file, and returned a different result. The figures came from the records, and the totals made sense.

Nothing magical happened to the model. I simply changed what it could see. Without the files, it predicted an answer. With the files, it calculated one.

Moving the Analysis Into Claude Code

I then shifted to Claude Code because I wanted to work toward a reusable application.

My first attempt gave us an unexpected result. Claude Code found local copies of the Olist files on my machine and used those. The answer was grounded, but the connection still depended on a single laptop and a single folder.

So I moved the dataset into Supabase PostgreSQL. Claude Code could now generate the SQL, run it against the database, and return the answer from a central source.

Repeating the Query Through MCP

The final step in Part 1 was to connect Claude Code to Supabase through MCP.

Once I authenticated the connection, Claude Code could inspect the tables and execute SQL through the server. The result stayed grounded, and the connection became reusable.

The workshop deck summarized the progression into three states: guess, direct, and MCP. The first person invented an answer. The second queried the source directly. The third used the same source through a standard connection.

By the end of Part 1, we had not built several applications. We tested several routes within a single grounded analytics workflow.

Build Part 2: Turning the Analysis Into a Dashboard

A correct answer in a chat window helps one person. A dashboard can make the analysis available to a team.

For the second build, I wanted a single-page application with business KPIs, revenue trends, category and seller performance, review data, and delivery information. It also had to stay connected to the database.

Preparing the Data Views

I first used AI to generate SQL for several database views. These views handled the larger joins and aggregations inside PostgreSQL, so the browser would only retrieve smaller summaries.

Then Claude Code found an issue. One view returned only the top five categories. Another returned only the top sellers. Those subsets could support charts, but not a true total revenue KPI. Claude Code compared my dashboard request with the available views, explained the mismatch, and asked whether it should create two more. I approved the change. It added a KPI summary and the other missing calculation before moving on.

This pause was crucial. Instead of inventing the missing total or forcing the wrong view into the design, they highlighted the gap.

Directing the Application Build

Once the views were ready, I gave Claude Code a detailed prompt for the front end.

I specified React with Vite, Recharts for the visualizations, Supabase JavaScript for the connection, a KPI row across the top, and the charts I wanted underneath. I also told it to read only from the prepared views. I did not write the React code or SQL by hand. I described the outcome and let the coding agent create the files.

I also showed a useful shortcut. I first told AI that I wanted a dashboard with useful KPIs and charts, then asked it to turn that idea into a stronger build prompt. I reviewed the result, but I did not need every framework term before starting.

Watching the First Run Fail

Claude Code created the application, connected the Supabase client, added the data-fetching logic, and produced the first interface.

Then the local run timed out.

I restarted the server, opened it again, and the data came through on the second attempt. I was glad that happened live. Coding agents can create and test a surprising amount of work, but databases still have limits, and human testing still matters.

The second run loaded the KPI cards and charts. More importantly, the values came from the Supabase views, not from hard-coded numbers in the front end.

Deploying the Dashboard

The last step was to move the application off my laptop.

I deployed it to Vercel and saved the Supabase URL and the anonymous key as environment variables. The configured direct connection string and service role key were not sent to the front end. The browser reads 6 read-only views. The application retrieved the required summaries, and PostgreSQL performed the calculations.

This also showed build time versus runtime in practice. AI and MCP helped create the views and application. Once deployed, the dashboard did not ask the model to recalculate everything whenever someone opened the page. It read the prepared data directly.

The source sat in an external database and could change. A refresh could pull updated figures without rebuilding the application.

A Quick Reality Check With ChartGen

After finishing the dashboard, I tested ChartGen, a tool that promises to turn a plain-English question into a chart. The interface looked good, and the idea was appealing. Upload the data, type one sentence, and get a visualization.

The outcome was still to be verified. The categories were in Portuguese, and the tool did not rely on the translation relationship, unlike our workflow. It also did not maintain the PostgreSQL connection I had hoped for. Each query consumed credits, which could become expensive with regular use.

That brought us back to the opening lesson. Fast chart generation is useful. It is not a substitute for understanding the source, joins, filters, and calculations behind the chart.

Where I Would Take the Build Next

The natural next step is to add a chat layer to the dashboard. A user could ask a question about the data, receive an answer, and inspect the SQL behind it.

That would need guardrails, query limits, and clear controls over what the chatbot can access. It would also need to stay focused on the data instead of answering unrelated questions. That was the challenge I left the audience with.

Take Your Skills Further

A four-hour Build-a-thon can show what is possible, but it cannot cover everything required to build production-grade agentic systems.

Simplilearn’s Microsoft Applied Agentic AI Program goes further into grounding, RAG, MCP, prompt engineering, multi-agent systems, deployment, observability, and production readiness. The focus is on moving from individual experiments to systems that can handle real users, multiple tools, and operational failures.

The result was the dashboard. The more significant aspect of that result was the underlying pathway. We went from something that sounded good to something that we can trace, test, and share.

Watch the complete Build-a-thon to see how an AI data agent and analytics dashboard are built, tested, and deployed using modern AI development tools and workflows.

Key Takeaways

• Without using the data, an AI can generate a well-crafted data answer
• The same question was based on a bit of a guess until grounding
• Part 1 examined a variety of connection techniques within a single, grounded workflow
• Part 2 took that analysis and built a deployed dashboard
• Before constructing the interface, Claude Code helped identify missing views
• While AI-generated applications may necessitate testing, security measures, and human review
• Any chart that you can follow the numbers back to is trustworthy