AI-Assisted Dashboard Builder: From Plain English to Live Executive Dashboard

Every dashboard project starts the same way: a stakeholder types a one-line brief into a ticket — "build me a SaaS churn dashboard" — and a developer spends two weeks wiring up the data, picking chart types, and tuning the layout. The dashboard builder concept has been around for years, but most "AI dashboard" demos stop at the headline: they generate a chart suggestion, or pick a chart type, or summarize existing data. None of them actually build the dashboard.

This demo does. Type a brief — or pick one of six preset templates — and Groq generates a complete dashboard spec on the fly: 4 KPI cards (top row) + 4 chart tiles (2×2 grid below), each with its own data, chart type, and configuration. The spec renders live in your browser using the same ECharts engine as our production deployments. No SQL, no data warehouse, no Power BI license, no two-week project.

Try It Now

Pick a preset template (SaaS, utility, customer service, supply chain, banking, IT operations), or type your own brief in plain English. The demo will call Groq via the Netlify-hosted proxy (the API key never reaches your browser), parse the JSON spec, show you the review card, then render the live dashboard. You can save the layout, export the JSON, regenerate with a different brief, or load a previously saved dashboard — all client-side.

What Just Happened

The demo ran a complete Brief → Spec → Render pipeline:

1. Read the brief — the user's plain-English description (or the preset template's pre-written brief). Max 800 characters. Sent to Groq as the user message in a chat completion request.
2. Sent a strict JSON-spec system prompt — the model is told exactly what shape the JSON must be: { title, description, kpis[4], charts[4] }, with each chart having a type field restricted to bar / line / area / stacked / pie / heatmap / gauge / scatter. The model is also told to synthesize plausible-looking numeric data (no real data sources — this is a demo).
3. Called Groq — via the Netlify-hosted proxy at startling-belekoy-b0ec70.netlify.app. The API key lives server-side as a Netlify env var; it never reaches the browser, never lives in the GitHub repo, never gets blocked by GitHub secret scanning.
4. Parsed + validated the JSON — robust parsing that strips ```json fences (in case the model adds them despite being told not to) and finds the outermost { ... } in the response (in case the model adds prose before/after). Validation enforces exactly 4 KPIs and exactly 4 charts; if validation fails, the user sees the error and can regenerate.
5. Rendered the review card — the parsed spec is shown as a human-readable card: dashboard title, description, 4 KPI cards with values + deltas, 4 chart tiles with type tags + descriptions. The user can inspect, export the JSON, or click Render Live Dashboard.
6. Rendered the live dashboard — the spec becomes an actual ECharts dashboard. 4 KPI cards across the top (with delta arrows), 4 chart tiles in a 2×2 grid below, each rendered using the appropriate ECharts option builder for its type (bar / line / area / stacked / pie / heatmap / gauge / scatter). Same palette as production (PALETTE constant), same chart configuration patterns.

What Makes This Different

The Architecture

The demo runs entirely in your browser. The only server-side component is the Groq proxy on Netlify — it adds the API key, forwards the request to Groq, and returns the response. No database, no SQL, no data warehouse. The chart data is synthetic — generated by the model itself based on the brief. In production, you'd replace the synthetic data with your real data sources, but the spec contract stays the same:

• Frontend — pure vanilla JS, no framework. Same pattern as the other live demos on this site: IIFE-wrapped, sessionStorage-based rate limit, HTML-escape everything user-or-AI-provided, no eval/Function, no alert/confirm/prompt.
• ECharts 5.5.0 via CDN — same engine as production. Same palette, same chart options, same animation. The chart option builders (one per type) are deliberately written to match the patterns in our universal-dashboard.js production renderer.
• Groq via Netlify proxy — the API key lives server-side as a Netlify env var. The browser calls /groq-proxy on the Netlify edge function, which forwards to api.groq.com with the key injected. The key never reaches the browser, never lives in the GitHub repo, never gets blocked by GitHub secret scanning.
• Strict JSON spec contract — the system prompt explicitly tells the model: return ONLY a JSON object, no markdown fences, no commentary. The schema enforces exactly 4 KPIs + exactly 4 charts, with chart types restricted to a known set. The robust parser strips fences and finds the outermost JSON object as a fallback.
• localStorage history — saved dashboards persist in the browser. The user can save the current spec, load a previously saved one, or delete it. No server round-trip.

From Demo to Production

The demo uses synthetic data because there's no real data source behind it. In production, the architecture extends in three places — and only three:

• Replace synthetic data with real data — instead of letting the model invent numbers, a backend service queries your actual data warehouse (SQL Server, Snowflake, BigQuery, Postgres) and injects the real numbers into the spec before rendering. The spec contract stays the same.
• Save to a real layout store — instead of localStorage, the spec is saved to dbo.DashboardLayoutVersion (or your equivalent) so it shows up in the version menu and is shareable across users with the existing ownership/access rules.
• Wire the bot to the saved layout — once the dashboard is saved as a native Studio layout, the existing dashboard assistant bot can answer questions about it: "what's the biggest driver of MRR growth this month?", "which queue has the worst resolution time?", "show me the at-risk accounts." The bot reads the spec's fields, aggregates, and filters — no extra AI calls needed.

The dashboard builder UX, the chart rendering, the palette, the KPI card layout, the chart-type option builders — none of those change between this demo and production. They're the same code, the same engine, the same patterns. That's the point.

The Honest Part

The chart data is synthetic. The model generates plausible-looking numbers (e.g. MRR = $4.2M, NRR = 118%, churn = 2.4%) but they are not real — they're invented to demonstrate the spec → render pipeline. In production, you'd inject real numbers from your data warehouse. The spec contract, the chart rendering, the KPI card layout, and the chart-type option builders all stay the same.

Groq is rate-limited to 10 AI calls per browser session (sessionStorage-tracked, resets on tab close). The model is qwen/qwen3.8-27b — fast, cheap, and accurate enough for the JSON spec generation task. For more complex briefs (multi-step pipelines, conversational refinement, large schema catalogs), you'd want a larger model — but for "brief → 8-tile dashboard spec", this is the right size at the right cost.

The preset templates cover six domains (SaaS, utility, customer service, supply chain, banking, IT operations). They're starting points, not constraints — the model can handle any brief in plain English, including domains we didn't preset. If the model returns a malformed spec (rare but possible — the model occasionally wraps JSON in fences despite being told not to), the parser strips the fences and tries again. If validation still fails, the user sees the error and the raw response, and can regenerate or rephrase the brief.