[AI] Building Dashboards Without BI SaaS: A Generative BI Platform Powered by Claude Code

I built a Generative BI platform where AI directly generates dashboard code — no BI SaaS required. Each dashboard is a standalone HTML file that contains only query definitions; actual data is fetched from BigQuery at view time. By leveraging Claude Code’s Skills, I standardized workflows so anyone can create, edit, and delete dashboards using natural language alone. This system was designed to complement the limitations of our existing AI NL2SQL Slack bot’s one-off analyses by turning them into persistent dashboards.

⚠️ All dashboards and data shown in this post are personally created samples and are not related to any actual metrics, business data, or strategic direction of my current employer.

Table of Contents

1. Introduction: The BI Tool Dilemma
2. BI as Code, and the Evolution to Generative BI
3. What It Looks Like
4. Architecture Deep Dive
5. The Zero Static Data Principle
6. Claude Code + Skills: Anyone Can Build Dashboards
7. AI NL2SQL Agent vs. Generative BI
8. Cost Savings
9. Limitations and Reflections

1. Introduction: The BI Tool Dilemma

As an Analytics Engineer, there’s a frustration I’ve always felt. I manage data transformation logic as code with dbt, automate orchestration with Airflow, and work with data through queries. Everything in the pipeline follows a Pipeline-as-Code approach with full version control. Yet when it comes to the final step of serving that data, many teams rely on BI SaaS tools like Looker, Tableau, or Redash.

With cloud-based BI services, costs scale with the number of users. Building a single dashboard requires learning the tool’s proprietary syntax and UI. Every request from business stakeholders — “I want a dashboard that shows X” — piles up in the data team’s backlog. Communication costs keep growing, and before you know it, the data team has become a so-called “dashboard factory.”

Having already built an AI NL2SQL Agent, I wanted to tackle this problem from the BI side as well.

• “What if we managed dashboards themselves as code, and AI generated that code?”
• “What if, instead of waiting for dashboard requests, AI could instantly create dashboards with validated queries?”

The idea started to take shape after watching a meetup talk on Agentic BI by Lightdash CEO Hamzah Chaudhary.

[embed]

2. BI as Code, and the Evolution to Generative BI

The Three Eras of BI

(1) First Generation (GUI-Based BI)

• Tableau, Looker, Redash, etc. — intuitive, but dashboard configuration is locked inside a GUI, making version control, code review, and automation difficult. And if it’s a cloud-based service, the high cost is hard to ignore.

(2) Second Generation (BI as Code)

• Tools like Lightdash and Evidence emerged. Dashboards are defined in Markdown or YAML and version-controlled with Git. However, access is still limited to “people who can write code.”

(3) Third Generation (Generative BI)

• AI receives natural language requests and directly generates dashboard code. It preserves the advantages of a code-based approach (version control, transparency, reproducibility) while maximizing accessibility through a natural language interface. This is exactly the idea I envisioned — a third-generation approach.

The Core Idea: Code Is the Dashboard

My core idea is remarkably simple. Each dashboard is a single static HTML file containing layout, query definitions, and visualization logic — all in one. No special build tools or compilation steps required. Open it in a browser, and it works as a dashboard. All these HTML files can be generated by users through natural language via Claude Code, and the entire foundation was built through straightforward Harness Engineering.

3. What It Looks Like

The Generative BI platform I built runs on DataHub + BigQuery as a multi-dashboard BI platform.

Main Home Page

Each Dashboard Page

Here’s a summary of the key features:

• Open index.html in a browser, and you can select dashboards from the sidebar.
• Each dashboard is an independent HTML file rendered inside an iframe.
• HTML files contain zero static data — data is fetched from BigQuery at page view time.
• Authentication is required via a gcloud OAuth token.
• When you need a new dashboard or want to edit/delete an existing one, you use Claude Code’s standardized Skills.

4. Architecture Deep Dive

Project Structure

📦 generative-bi/
├── 📄 index.html                    ← Main platform (sidebar + iframe)
├── 📁 dashboards/
│   ├── 📄 _registry.js              ← Dashboard list registry
│   ├── 📁 lib/
│   │   ├── 📄 dabi-core.js          ← Shared JS (BigQuery client, token, formatters)
│   │   └── 📄 dabi-dashboard.css    ← Shared CSS (variables, layout, components)
│   ├── 📁 (Sample) Revenue Monitoring/
│   │   └── 📄 live-revenue.html
│   ├── 📁 (Sample) App KPI/
│   │   └── 📄 app-kpi.html
│   ├── 📁 (Sample) User Analytics/
│   │   └── 📄 user-value-segmentation.html
│   └── 📁 (Sample) Product Analytics/
│       ├── 📄 retention-aha-moment.html
│       ├── 📄 app-session-analysis.html
│       └── 📄 review-analysis.html
├── 📁 assets/                        ← Logo images
├── 📁 scripts/
│   └── 📄 update-sidebar.sh          ← Auto-generate registry script
└── 📁 .claude/
    ├── 📄 color-guide.md             ← Brand color palette
    └── 📁 skills/
        ├── 📁 add-dashboard/         ← Dashboard creation skill
        ├── 📁 edit-dashboard/        ← Dashboard editing skill
        └── 📁 remove-dashboard/      ← Dashboard deletion skill

Key Design Decisions

(1) One HTML File = One Dashboard

Each dashboard page is a standalone HTML file. I eliminated the need for build tools, bundlers, or frameworks — intentionally, so that non-developer colleagues could easily work with it. Common structures reference the shared libraries dabi-core.js and dabi-dashboard.css, while each dashboard's unique logic is included inline.

(2) iframe Isolation and postMessage Communication

index.html loads each dashboard in an iframe and passes the gcloud OAuth token via postMessage. This way, dashboards don't contaminate each other's state, while sensitive information like tokens can be shared securely.

(3) Category = Folder Name

There’s no separate category field in _registry.js. Instead, the folder name is parsed and used as the category. For example, in (Sample) Revenue Monitoring/live-revenue.html, (Sample) Revenue Monitoring becomes the category. The intent is for the file system structure to directly mirror the information architecture.

5. The Zero Static Data Principle

Since I designed for maximum usability by letting users keep dashboards as files, I naturally had to be mindful of the data security trade-off. I addressed this with three principles:

(1) No data is stored in HTML files.

Each HTML file contains only query definitions — no actual data (numbers). Every time a dashboard is opened, it queries BigQuery and renders the results. This means even if an HTML file is exposed externally, it contains only query text — not a single line of actual business data.

(2) gcloud OAuth Token-Based Authentication

Accessing BigQuery requires an OAuth token issued via gcloud auth print-access-token. This token has the following characteristics:

• 1-hour expiry: Even if a token is compromised, its validity window is extremely short.
• Per-user issuance: Who accessed what data is fully traceable through Google Cloud IAM logs.
• Centralized access control: Accessible datasets are determined centrally through BigQuery project IAM policies.

Tokens are temporarily stored in localStorage to persist across page refreshes, but are automatically deleted upon expiration, prompting re-entry.

Connect with OAuth Token Page

6. Claude Code + Skills: Anyone Can Build Dashboards

(1) Generative BI vs. Traditional Process

(2) Skills: Standardized Workflows

I created a total of four Skills:

• /add-dashboard: Create a new dashboard
• /edit-dashboard: Edit an existing dashboard
• /remove-dashboard: Delete an existing dashboard
• /update-sidebar: Update the sidebar

Each Skill is a standardized workflow that instructs: “Follow this sequence, use these MCP Tools, and adhere to these rules.” The reason I built these was to maximize consistency. For example, the /add-dashboard Skill enforces the following procedures:

• DataHub First Principle: Before writing any query, always verify table information in DataHub. This prevents mistakes from using incorrect tables or columns.
• BigQuery Validation: Execute the written queries to verify results. Catch syntax errors or result anomalies in advance.
• Business Logic Compliance: Specify the business rules required for data retrieval.
• Design System Compliance: Mandate the use of dabi-core.js and dabi-dashboard.css.

Example interaction:

💬 User:
/add-dashboard Create a retention dashboard.
Daily from D0 to D180, monthly from M0 to M6,
from Signup-to-Login and First Purchase-to-Purchase perspectives,
for all users and by each segment.

🤖 Claude:
(1) Searching for retention-related tables in DataHub…
(2) Confirmed dim_xxx_xxx schema
(3) Wrote 4 queries and validated via BigQuery execution
(4) Created dashboards/(Sample) Product Analytics/retention.html
(5) Updated _registry.js

✅ Your retention dashboard has been created!

In short, I built these as Skills to maximize user interface freedom while adhering to the minimum principles and workflows required during development — all without writing a single line of code or query.

7. AI NL2SQL Agent vs. Generative BI

Several months ago, I deployed an AI data analysis Slack bot that is now used by roughly 80% of colleagues company-wide. It receives natural language questions in Slack, looks up DataHub, then executes queries on BigQuery and returns results in Slack markdown format.

[embed][AI] Building an AI Data Analysis Bot for Slack - Handle Data Requests Right in Slack Ask @dahae What caused the sudden spike in DAU yesterday? in Slack, and it identifies tables and schemas from DataHub…joshua-data.medium.com

However, this Slack bot has a fundamental limitation: it’s one-off. To check revenue trends, you’d need to ask “Show me the last 30 days of revenue” every single day. I wanted Generative BI to overcome this “one-off” nature by making analyses persistent.

This doesn’t mean the Slack bot is unnecessary. For one-off ad-hoc questions, the Slack bot is more suitable. But for metrics that need to be monitored repeatedly, the Generative BI platform complements the Slack bot’s limitations.

8. Cost Savings

• BI SaaS cost: None.
• BI tool learning cost: None.
• BigQuery query cost: Does not exceed the query volume that would be generated by a BI SaaS.
• Claude Max Plan: No additional cost if usage limits are applied.
• Other: No UI feature constraints from BI vendors, and no vendor lock-in for management logic.

9. Limitations and Reflections

(1) Limitations

The biggest limitation of this Generative BI platform, which started from a small idea of mine, is that it’s inconvenient to share with colleagues.

It exists only as a client-side application running in a local environment (file://) with no backend server or hosting. To share personally created dashboards with colleagues, the best options are sharing via Git or sending a compressed codebase — which can be cumbersome for non-developers.

Since I built this as a prototype without additional infrastructure costs, I haven’t resolved this issue yet — but it’s something I plan to think more deeply about.

(2) Reflections

From building the AI NL2SQL Agent to the Generative BI platform, I’ve been deeply reflecting on “how the role of Analytics Engineer should evolve.”

• The traditional AE workflow: Receive data request → Analyze requirements & semantics → dbt modeling → DQ testing & staging deployment → Production deployment → Dashboard visualization → Deliver results
• The AI-native AE workflow: Design data infrastructure & system architecture → Harness Engineering & AI workflow development → Quality management → Organization-wide data accessibility enablement

In other words, I’m increasingly feeling that the competencies an AE needs to focus on are expanding over time:

• From building models and delivering dashboards → to designing and implementing workflows that enable dashboard creation
• From processing data requests → to building pipelines where requests are handled automatically
• From operating BI tools → to designing context structures and guides that help AI generate BI effectively

Ultimately, roles are leveling up much faster than before — and we’re in a situation where they must level up. Junior and Senior engineers need to develop Staff-level thinking, going beyond simply executing technical requirements to considering organization-wide impact.