How to Build a Dashboard: Data Sources, KPIs, Charts and Access
How to build a data dashboard with AI: choose the questions and KPIs, connect data sources, pick the right charts, control who sees what, and keep numbers true.
Mythex Team · · 6 min read
To build a dashboard, start from the questions it must answer and the people who will read it, define a small set of metrics precisely, connect the data those metrics come from, and choose a simple chart for each. Then decide who can see which numbers. An AI app builder can generate a polished dashboard in minutes; the hard part, and the part that decides whether anyone trusts it, is getting the data and definitions right.
Start with questions, not charts
A dashboard that tries to show everything gets opened once. Before you think about charts, answer:
- Who is it for? The founder, a sales team, operations, investors, your customers?
- What decisions does it support? "Do we need to hire another support person?" is a question a dashboard can answer. "Show me our data" is not.
- How often will they look? Daily operations dashboards need fresh data and alerts; a monthly board view doesn't.
Write three to five questions. Each becomes one or two metrics.
Define each metric exactly
Most dashboard arguments are really definition arguments. Write a short definition for every number:
| Metric | Vague | Precise |
|---|---|---|
| Revenue | "Money we made" | Sum of paid invoice totals, excluding tax, by invoice date, in USD |
| Active users | "People using it" | Distinct users with at least one login in the last 30 days |
| Churn | "People who left" | Paying customers at the start of the month who cancelled during it, divided by customers at the start |
| Response time | "How fast support is" | Median hours from ticket creation to first human reply, business days only |
Paste these definitions into your prompt. An AI will otherwise pick a reasonable-sounding calculation that may not match how your business counts.
Where the data comes from
| Source | How a dashboard reads it | Watch out for |
|---|---|---|
| Your app's own database | Direct queries | Heavy queries slowing the main app; add summary tables if needed |
| A spreadsheet | Import as CSV, or read it through an API | Manual editing breaks formats; totals rows and merged cells |
| SaaS tools (Stripe, HubSpot, Shopify, Google Analytics) | Their APIs with your API key | Rate limits, pagination, and each tool defining metrics its own way |
| A data warehouse (BigQuery, Snowflake, Postgres) | SQL through a server-side connection | Credentials and query costs |
Two principles apply everywhere:
- Keep keys on the server. API keys and database passwords belong in the app's environment variables, never in browser code.
- Decide on freshness. Pulling from several APIs on every page load is slow and can hit rate limits. For most business dashboards, a sync every hour or overnight into your own database, with a "last updated" time on the page, is simpler and more reliable.
If APIs are new to you, what is an API and what is a database explain the basics.
Choose the right chart
- Single number with change ("$42k, up 8% vs last month") — a KPI card. The most useful element on most dashboards.
- Trend over time — a line chart. Use bars only for a small number of periods.
- Comparing categories — a horizontal bar chart, sorted by value.
- Part of a whole — a stacked bar. Pie charts work only with two or three slices.
- Detail and exceptions — a table with sorting, search and filters. Often more useful than any chart.
Keep colours consistent: one colour for "this period", a muted one for "comparison", red only for things that need attention.
Who sees what
Decide access before building:
- Internal, everyone sees everything — simplest. Still needs login if it holds business data.
- Role-based — sales sees sales numbers, finance sees margins, managers see their own team.
- Customer-facing — each customer sees only their own data. Every query must filter by the customer's account on the server. Test it by logging in as two different customers.
A dashboard with revenue or customer data on a public URL without login is a data leak waiting to be found.
A first prompt that works
Build a sales dashboard for a 10-person B2B software company. Audience: the founders and the sales lead, checking it every Monday. Overview page: KPI cards for new MRR this month, total MRR, new customers this month, churned customers this month and pipeline value, each with the change against last month; a line chart of MRR over the last 12 months; a bar chart of new deals by source. A Deals page with a searchable, sortable table (company, owner, value, stage, close date) and filters by owner and stage. Metric definitions: MRR is the sum of active monthly subscription amounts, annual plans divided by 12; churn counts customers whose subscription ended this month. Use realistic sample data in a database for now — we'll connect Stripe later. Show a "last updated" time. Login required. Clean sidebar layout.
It names the audience, each metric with its definition, the charts and the data plan — and starts with sample data, so you can agree on the design before connecting real sources.
Build steps
- Layout with sample data. Agree on the metrics and charts while the data is fake and cheap to change.
- Connect one real source. Check every number against the source system by hand. If MRR differs from what Stripe shows, find out why before going further.
- Add the other sources, one at a time, checking each.
- Scheduled refresh or on-load queries, with a "last updated" label.
- Filters — date range first, then the one or two others people ask for.
- Login and roles.
- Empty and error states — what the page shows when a source is down or a filter returns nothing.
- Share it with the audience, then remove anything nobody looks at after a month.
Make it fast
A slow dashboard gets checked less. Precompute totals that are expensive to calculate (a daily summary table instead of scanning every order), paginate large tables, and load the headline cards first so the page is useful before the charts finish. If a number takes a long time to compute, show when it was last calculated rather than recalculating it on every visit.
Common mistakes
- Too many charts. If everything is highlighted, nothing is.
- Undefined metrics. Two people reading the same dashboard should reach the same conclusion.
- Never checking numbers against the source. One wrong figure and people stop trusting the whole dashboard.
- Querying every API on every page load. Slow, fragile and sometimes expensive.
- No date context. Always show the period and the comparison.
- Secrets in the frontend. An API key visible in the browser can be copied by anyone who opens the page.
When a BI tool is the better choice
If your data already sits in a database or warehouse and the main users are analysts who want to explore it, slice it and build their own charts, a BI tool — Looker Studio, Power BI, Metabase and others — will serve them better than a custom build. Many SaaS tools also have good built-in reports; check those before rebuilding them. A custom dashboard wins when it is for customers or non-analysts, needs logic or permissions the BI tool can't express, combines sources in a way specific to your business, or belongs inside a product you already run.
If the job is less about viewing numbers and more about changing records, you want an admin panel or internal tool instead — see how to build an internal tool. And if your numbers live in a spreadsheet today, how to turn a spreadsheet into an app is a good next read.
Building it with Mythex
On Mythex you describe the dashboard and the agent builds the pages and charts in a live preview, starting with realistic sample data and moving to a dedicated Postgres database when the numbers need to persist. The docs' dashboard use case has a starter prompt. If your data is in a tool like Google Sheets, you can connect the account through Connectors and ask the agent to read it and build a dashboard from it.
There are no built-in warehouse connectors for the app itself — for BigQuery, Snowflake, Stripe and similar, the app calls their APIs with keys you store as project secrets. Logins and roles for the people viewing the dashboard are part of the app you build. To start from a prompt, browse the dashboard templates, such as the metrics dashboard.
Questions
How do I build a dashboard?
Decide who the dashboard is for and which questions it must answer, pick a handful of metrics with exact definitions, connect the data sources, then choose a chart for each metric. An AI app builder can generate the pages and charts from a description once you know those things.
How many KPIs should a dashboard have?
Few enough that someone can take them in at a glance — often five to seven on the main view. Put detail on separate pages that people open when a headline number looks wrong.
Should I build a custom dashboard or use a BI tool?
Use a BI tool such as Looker Studio, Power BI or Metabase when your data already sits in a supported database or warehouse and analysts will explore it. Build a custom dashboard when it is for customers or non-analysts, needs your own logic or permissions, or sits inside an app you already have.
Can a dashboard show live data?
Yes, if it reads from a database or API when the page loads or on a refresh interval. For many business dashboards, data refreshed every hour or every day is enough and is simpler and cheaper to run.