Building a Dashboard with AI: What Actually Works
"Build me a dashboard" is one of the most common things people now ask a coding agent, and one of the least reliable. The first result is impressive. The fourth iteration is usually where the enthusiasm goes.
The interesting thing is that the failure isn't evenly distributed. AI is very good at one half of this problem and consistently poor at the other, and once you can tell which half you're in, the whole exercise gets cheap.
What AI is genuinely good at here
Writing a data endpoint. This is close to an ideal task for a language model:
The input is well specified — an API you name, a database schema it can read, a metric you describe in a sentence.
The output is small, self-contained, and easy to check by running it.
The domain is enormously well represented in training data. Paginating a REST API and summing a field is not a novel problem.
Correctness is verifiable. You call the endpoint and look at the number.
Ask an agent to "write a handler that computes MRR from Stripe subscriptions, normalising annual plans to monthly," and you will get something close to right on the first attempt, and right on the second.
The failure mode: asking it for the whole dashboard
Ask for the dashboard instead — the app, the charts, the layout — and you get something that demos well and ages badly.
The chart library is a moving target. Agents write against whichever major version dominated their training data. The config keys shift between versions, and the resulting code fails in ways that read as plausible.
Layout is where the iterations go. "Make the chart smaller." "Now it's clipped on mobile." "The legend overlaps." Each round is cheap; the sequence is not, and none of it is work you learn anything from.
You now own an app. Auth for the second viewer, hosting, a build pipeline, dependency upgrades. The agent generated it in an afternoon and will not be maintaining it.
Nothing is verifiable. There's no test for "the dashboard looks right." You are the test suite, forever.
That's the same ownership trap as building dashboards by hand, just entered faster and with less understanding of what got built. Generated code you didn't write is still code you have to keep alive.
The narrow version that works
Split the problem where the model's competence splits:
Let the agent write the endpoint. Don't let it write the frontend.
If a rendering layer already exists and accepts a fixed JSON shape, the agent's job collapses to the part it's good at: fetch the data, compute the number, return this exact structure. No chart library, no layout, no hosting, no app.
The contract is what makes this work. An agent guessing at what "dashboard JSON" means will invent something reasonable and wrong — { "value": 1234, "label": "MRR", "trend": "up" } looks fine and renders nowhere. Given the real schema up front, it hits it first time.
Here's the actual shape a KPI widget takes:
{ "title": "MRR", "actions": [ { "title": "View Details", "type": "link", "url": "https://example.com/mrr-details" } ], "data": { "header": { "title": "$12,345", "subtitle": "vs last month", "badge": { "text": "+$1,120", "icon": "ArrowUp", "color": "Success" } } } }
title and data are required; actions and the optional alert object are there when you need them. Charts use the same envelope with labels and datasets inside data. That's the whole surface an agent has to learn.
And it's checkable without an account: paste a generated response into the free endpoint validator and it tells you whether a widget can render it. That gives the loop something it usually lacks — a fast, objective pass/fail that isn't your opinion about a screenshot.
Two ways to generate the endpoint
Both routes exist because people arrive at this from different directions.
If you run an agent, install the Skill. The dashboardbase Skill is free and open source. Drop the dashboardbase/ folder into Claude Code's or Cursor's skills directory and the agent has the whole contract — response envelope, every widget schema, authentication, setup files, webhook events. Tools without skills support can paste SKILL.md into the chat as a plain prompt. From then on, "add a churn widget" produces a correctly-shaped endpoint rather than a near-miss.
If you'd rather not set up an agent, generate the prompt instead. Adding a widget offers Build my endpoint with AI: describe what you want, and the editor produces a copy-pasteable prompt for whatever tool you already use. There's a version that covers a whole dashboard in one prompt, too.
Two things about that prompt are worth being precise about, because this is where AI features usually overclaim:
It's a reviewable draft, not a black box. The editor invites you to read and edit it before running, and says plainly that it's plain text built only from what you typed — no secrets, no hidden instructions.
Nothing runs on our side. The prompt is generated in your browser. It goes nowhere until you paste it into your own tool, and the code it produces runs in your own environment.
"Easy to generate" is a fair claim. "We write your backend for you" would not be, and we'd rather you knew the difference before you started.
Getting the result back into a dashboard
There's a handoff problem in this loop that's easy to miss: the agent produces endpoints, and someone still has to create the widgets, pick types, and wire URLs.
A setup file closes that gap. An agent that knows the contract can emit one describing the whole dashboard, and Create link in the export modal turns it into a short URL. Open the link and you get a preview first — the dashboard's title, how many widgets it will create, the widget types, and, shown prominently, the server it will connect to. Nobody points an importer at a host without seeing which one.
No account is needed to look, links carry no credentials, and the expiry is shown as an absolute time when the link is created. On a phone the link opens the app directly, so an agent's output in a chat window can become a live dashboard without opening a laptop.
That's the shape of the loop worth building: describe → generate → validate → import. Every step has a check in it.
What AI still won't decide for you
The generation is the easy half. The judgment isn't, and it's most of the value.
Which numbers belong on the board. An agent will happily generate twelve widgets. Six is usually the right answer, and knowing which six is a business decision, not a code-generation one.
What your metric actually means. Does a trialing customer count toward MRR? Do you net out refunds? The model will pick a convention and not tell you it picked one. That definition is the part only you can supply — write it down, in a comment, in your own code.
Whether the number is right. An endpoint that returns a plausible figure is the most expensive bug in this whole workflow, because dashboards are trusted by default. Check the first value against a source you already believe.
Security. Ask explicitly for the auth check. Your endpoint should reject any request without the workspace endpoint secret in the
x-dashboardbase-secretheader, and fail at boot if the secret isn't configured. Validation will tell you the truth here — testing a datasource fires one extra request with every credential stripped and reports what actually came back.
The honest bottom line
AI didn't make dashboards free. It made one part of building them nearly free — the data endpoint — while leaving the expensive parts exactly where they were: deciding what to show, and owning whatever renders it.
The move is to take the free part and refuse the expensive one. Give an agent a fixed contract, let it write fifteen lines of backend code you'd have written anyway, and don't ask it for a frontend you'll be maintaining in a year.
If you're weighing this against the other routes, how to build a dashboard lays all three out side by side. Or install the Skill, ask for one widget, and see what comes back — that's a fifteen-minute experiment, and the validator will tell you immediately whether it worked.
Building a Dashboard with AI: What Actually Works
"Build me a dashboard" is one of the most common things people now ask a coding agent, and one of the least reliable. The first result is impressive. The fourth iteration is usually where the enthusiasm goes.
The interesting thing is that the failure isn't evenly distributed. AI is very good at one half of this problem and consistently poor at the other, and once you can tell which half you're in, the whole exercise gets cheap.
What AI is genuinely good at here
Writing a data endpoint. This is close to an ideal task for a language model:
The input is well specified — an API you name, a database schema it can read, a metric you describe in a sentence.
The output is small, self-contained, and easy to check by running it.
The domain is enormously well represented in training data. Paginating a REST API and summing a field is not a novel problem.
Correctness is verifiable. You call the endpoint and look at the number.
Ask an agent to "write a handler that computes MRR from Stripe subscriptions, normalising annual plans to monthly," and you will get something close to right on the first attempt, and right on the second.
The failure mode: asking it for the whole dashboard
Ask for the dashboard instead — the app, the charts, the layout — and you get something that demos well and ages badly.
The chart library is a moving target. Agents write against whichever major version dominated their training data. The config keys shift between versions, and the resulting code fails in ways that read as plausible.
Layout is where the iterations go. "Make the chart smaller." "Now it's clipped on mobile." "The legend overlaps." Each round is cheap; the sequence is not, and none of it is work you learn anything from.
You now own an app. Auth for the second viewer, hosting, a build pipeline, dependency upgrades. The agent generated it in an afternoon and will not be maintaining it.
Nothing is verifiable. There's no test for "the dashboard looks right." You are the test suite, forever.
That's the same ownership trap as building dashboards by hand, just entered faster and with less understanding of what got built. Generated code you didn't write is still code you have to keep alive.
The narrow version that works
Split the problem where the model's competence splits:
Let the agent write the endpoint. Don't let it write the frontend.
If a rendering layer already exists and accepts a fixed JSON shape, the agent's job collapses to the part it's good at: fetch the data, compute the number, return this exact structure. No chart library, no layout, no hosting, no app.
The contract is what makes this work. An agent guessing at what "dashboard JSON" means will invent something reasonable and wrong — { "value": 1234, "label": "MRR", "trend": "up" } looks fine and renders nowhere. Given the real schema up front, it hits it first time.
Here's the actual shape a KPI widget takes:
{ "title": "MRR", "actions": [ { "title": "View Details", "type": "link", "url": "https://example.com/mrr-details" } ], "data": { "header": { "title": "$12,345", "subtitle": "vs last month", "badge": { "text": "+$1,120", "icon": "ArrowUp", "color": "Success" } } } }
title and data are required; actions and the optional alert object are there when you need them. Charts use the same envelope with labels and datasets inside data. That's the whole surface an agent has to learn.
And it's checkable without an account: paste a generated response into the free endpoint validator and it tells you whether a widget can render it. That gives the loop something it usually lacks — a fast, objective pass/fail that isn't your opinion about a screenshot.
Two ways to generate the endpoint
Both routes exist because people arrive at this from different directions.
If you run an agent, install the Skill. The dashboardbase Skill is free and open source. Drop the dashboardbase/ folder into Claude Code's or Cursor's skills directory and the agent has the whole contract — response envelope, every widget schema, authentication, setup files, webhook events. Tools without skills support can paste SKILL.md into the chat as a plain prompt. From then on, "add a churn widget" produces a correctly-shaped endpoint rather than a near-miss.
If you'd rather not set up an agent, generate the prompt instead. Adding a widget offers Build my endpoint with AI: describe what you want, and the editor produces a copy-pasteable prompt for whatever tool you already use. There's a version that covers a whole dashboard in one prompt, too.
Two things about that prompt are worth being precise about, because this is where AI features usually overclaim:
It's a reviewable draft, not a black box. The editor invites you to read and edit it before running, and says plainly that it's plain text built only from what you typed — no secrets, no hidden instructions.
Nothing runs on our side. The prompt is generated in your browser. It goes nowhere until you paste it into your own tool, and the code it produces runs in your own environment.
"Easy to generate" is a fair claim. "We write your backend for you" would not be, and we'd rather you knew the difference before you started.
Getting the result back into a dashboard
There's a handoff problem in this loop that's easy to miss: the agent produces endpoints, and someone still has to create the widgets, pick types, and wire URLs.
A setup file closes that gap. An agent that knows the contract can emit one describing the whole dashboard, and Create link in the export modal turns it into a short URL. Open the link and you get a preview first — the dashboard's title, how many widgets it will create, the widget types, and, shown prominently, the server it will connect to. Nobody points an importer at a host without seeing which one.
No account is needed to look, links carry no credentials, and the expiry is shown as an absolute time when the link is created. On a phone the link opens the app directly, so an agent's output in a chat window can become a live dashboard without opening a laptop.
That's the shape of the loop worth building: describe → generate → validate → import. Every step has a check in it.
What AI still won't decide for you
The generation is the easy half. The judgment isn't, and it's most of the value.
Which numbers belong on the board. An agent will happily generate twelve widgets. Six is usually the right answer, and knowing which six is a business decision, not a code-generation one.
What your metric actually means. Does a trialing customer count toward MRR? Do you net out refunds? The model will pick a convention and not tell you it picked one. That definition is the part only you can supply — write it down, in a comment, in your own code.
Whether the number is right. An endpoint that returns a plausible figure is the most expensive bug in this whole workflow, because dashboards are trusted by default. Check the first value against a source you already believe.
Security. Ask explicitly for the auth check. Your endpoint should reject any request without the workspace endpoint secret in the
x-dashboardbase-secretheader, and fail at boot if the secret isn't configured. Validation will tell you the truth here — testing a datasource fires one extra request with every credential stripped and reports what actually came back.
The honest bottom line
AI didn't make dashboards free. It made one part of building them nearly free — the data endpoint — while leaving the expensive parts exactly where they were: deciding what to show, and owning whatever renders it.
The move is to take the free part and refuse the expensive one. Give an agent a fixed contract, let it write fifteen lines of backend code you'd have written anyway, and don't ask it for a frontend you'll be maintaining in a year.
If you're weighing this against the other routes, how to build a dashboard lays all three out side by side. Or install the Skill, ask for one widget, and see what comes back — that's a fifteen-minute experiment, and the validator will tell you immediately whether it worked.
Building a Dashboard with AI: What Actually Works
"Build me a dashboard" is one of the most common things people now ask a coding agent, and one of the least reliable. The first result is impressive. The fourth iteration is usually where the enthusiasm goes.
The interesting thing is that the failure isn't evenly distributed. AI is very good at one half of this problem and consistently poor at the other, and once you can tell which half you're in, the whole exercise gets cheap.
What AI is genuinely good at here
Writing a data endpoint. This is close to an ideal task for a language model:
The input is well specified — an API you name, a database schema it can read, a metric you describe in a sentence.
The output is small, self-contained, and easy to check by running it.
The domain is enormously well represented in training data. Paginating a REST API and summing a field is not a novel problem.
Correctness is verifiable. You call the endpoint and look at the number.
Ask an agent to "write a handler that computes MRR from Stripe subscriptions, normalising annual plans to monthly," and you will get something close to right on the first attempt, and right on the second.
The failure mode: asking it for the whole dashboard
Ask for the dashboard instead — the app, the charts, the layout — and you get something that demos well and ages badly.
The chart library is a moving target. Agents write against whichever major version dominated their training data. The config keys shift between versions, and the resulting code fails in ways that read as plausible.
Layout is where the iterations go. "Make the chart smaller." "Now it's clipped on mobile." "The legend overlaps." Each round is cheap; the sequence is not, and none of it is work you learn anything from.
You now own an app. Auth for the second viewer, hosting, a build pipeline, dependency upgrades. The agent generated it in an afternoon and will not be maintaining it.
Nothing is verifiable. There's no test for "the dashboard looks right." You are the test suite, forever.
That's the same ownership trap as building dashboards by hand, just entered faster and with less understanding of what got built. Generated code you didn't write is still code you have to keep alive.
The narrow version that works
Split the problem where the model's competence splits:
Let the agent write the endpoint. Don't let it write the frontend.
If a rendering layer already exists and accepts a fixed JSON shape, the agent's job collapses to the part it's good at: fetch the data, compute the number, return this exact structure. No chart library, no layout, no hosting, no app.
The contract is what makes this work. An agent guessing at what "dashboard JSON" means will invent something reasonable and wrong — { "value": 1234, "label": "MRR", "trend": "up" } looks fine and renders nowhere. Given the real schema up front, it hits it first time.
Here's the actual shape a KPI widget takes:
{ "title": "MRR", "actions": [ { "title": "View Details", "type": "link", "url": "https://example.com/mrr-details" } ], "data": { "header": { "title": "$12,345", "subtitle": "vs last month", "badge": { "text": "+$1,120", "icon": "ArrowUp", "color": "Success" } } } }
title and data are required; actions and the optional alert object are there when you need them. Charts use the same envelope with labels and datasets inside data. That's the whole surface an agent has to learn.
And it's checkable without an account: paste a generated response into the free endpoint validator and it tells you whether a widget can render it. That gives the loop something it usually lacks — a fast, objective pass/fail that isn't your opinion about a screenshot.
Two ways to generate the endpoint
Both routes exist because people arrive at this from different directions.
If you run an agent, install the Skill. The dashboardbase Skill is free and open source. Drop the dashboardbase/ folder into Claude Code's or Cursor's skills directory and the agent has the whole contract — response envelope, every widget schema, authentication, setup files, webhook events. Tools without skills support can paste SKILL.md into the chat as a plain prompt. From then on, "add a churn widget" produces a correctly-shaped endpoint rather than a near-miss.
If you'd rather not set up an agent, generate the prompt instead. Adding a widget offers Build my endpoint with AI: describe what you want, and the editor produces a copy-pasteable prompt for whatever tool you already use. There's a version that covers a whole dashboard in one prompt, too.
Two things about that prompt are worth being precise about, because this is where AI features usually overclaim:
It's a reviewable draft, not a black box. The editor invites you to read and edit it before running, and says plainly that it's plain text built only from what you typed — no secrets, no hidden instructions.
Nothing runs on our side. The prompt is generated in your browser. It goes nowhere until you paste it into your own tool, and the code it produces runs in your own environment.
"Easy to generate" is a fair claim. "We write your backend for you" would not be, and we'd rather you knew the difference before you started.
Getting the result back into a dashboard
There's a handoff problem in this loop that's easy to miss: the agent produces endpoints, and someone still has to create the widgets, pick types, and wire URLs.
A setup file closes that gap. An agent that knows the contract can emit one describing the whole dashboard, and Create link in the export modal turns it into a short URL. Open the link and you get a preview first — the dashboard's title, how many widgets it will create, the widget types, and, shown prominently, the server it will connect to. Nobody points an importer at a host without seeing which one.
No account is needed to look, links carry no credentials, and the expiry is shown as an absolute time when the link is created. On a phone the link opens the app directly, so an agent's output in a chat window can become a live dashboard without opening a laptop.
That's the shape of the loop worth building: describe → generate → validate → import. Every step has a check in it.
What AI still won't decide for you
The generation is the easy half. The judgment isn't, and it's most of the value.
Which numbers belong on the board. An agent will happily generate twelve widgets. Six is usually the right answer, and knowing which six is a business decision, not a code-generation one.
What your metric actually means. Does a trialing customer count toward MRR? Do you net out refunds? The model will pick a convention and not tell you it picked one. That definition is the part only you can supply — write it down, in a comment, in your own code.
Whether the number is right. An endpoint that returns a plausible figure is the most expensive bug in this whole workflow, because dashboards are trusted by default. Check the first value against a source you already believe.
Security. Ask explicitly for the auth check. Your endpoint should reject any request without the workspace endpoint secret in the
x-dashboardbase-secretheader, and fail at boot if the secret isn't configured. Validation will tell you the truth here — testing a datasource fires one extra request with every credential stripped and reports what actually came back.
The honest bottom line
AI didn't make dashboards free. It made one part of building them nearly free — the data endpoint — while leaving the expensive parts exactly where they were: deciding what to show, and owning whatever renders it.
The move is to take the free part and refuse the expensive one. Give an agent a fixed contract, let it write fifteen lines of backend code you'd have written anyway, and don't ask it for a frontend you'll be maintaining in a year.
If you're weighing this against the other routes, how to build a dashboard lays all three out side by side. Or install the Skill, ask for one widget, and see what comes back — that's a fifteen-minute experiment, and the validator will tell you immediately whether it worked.