Start with data, not design
The most common mistake when asking Claude Code to build a dashboard is opening with a design request. 'Build me a sales dashboard with charts and filters' gets you a generic template with placeholder data - and once you try to connect your actual numbers, the structure rarely fits.
The right first message is: here is a sample of my actual data, and here are the three metrics I most need to see. Start with the shape of the data. Claude Code will propose a component structure that fits the data - not a dashboard skin that you then have to reverse-engineer to accept real inputs.
Four things to specify before Claude Code touches the UI
Clear specs upfront prevent the back-and-forth that stretches a one-session build into four. These four questions cover everything Claude Code needs to build a dashboard that actually fits your situation:
- What is the data source? Tell Claude Code exactly: a static CSV, a Supabase table, a fetch call to a URL, or hardcoded data for now. Being vague here leads to a dashboard that works in demo mode and breaks when you connect real data.
- Which three to five metrics need to be immediately visible above the scroll? Dashboards fail when they try to show everything. Name the three numbers you look at first every morning.
- Does it need time-range filtering? A date-range filter that recomputes all charts simultaneously is a separate piece of logic. Decide now whether you need it - adding it after the fact is more work than building it in from the start.
- Will it update in real-time or load once? Real-time means polling or WebSockets; load-once means a fetch on mount. These are different architectures. Telling Claude Code upfront prevents a rebuild at the data layer later.
Walking Claude Code through the build in stages
A dashboard build works best when you review after each stage rather than asking for everything in one message. Here is the sequence that works:
- First message: 'Here is a sample of my data: [paste JSON or CSV]. Build me a React component that displays [metric 1], [metric 2], and [metric 3]. Use a bar chart for [X] and number cards for [Y and Z].' Review the output before continuing.
- Second message: 'Add a date-range filter that recomputes all charts when the range changes. The default range should be the last 30 days.' Review the filter logic before continuing.
- Third message: 'Make the layout responsive. Cards should stack vertically on mobile. Charts should be full-width below 768px.' Test on a narrowed browser window before continuing.
- Fourth message (if needed): 'Replace the hardcoded sample data with a fetch from [your actual data source].' Do this last, after the layout is stable.
Dashboard types and what to tell Claude Code for each
The first message to Claude Code should include the type of data and the metric names. Here is what to specify for the most common business dashboard types:
- Revenue or sales dashboard: a time-series line chart for revenue over time, number cards for total revenue this month vs last month, and a bar chart for revenue by product or client. Tell Claude Code the time resolution: daily, weekly, or monthly.
- Operations or status dashboard: status indicator chips (green/yellow/red) for the key systems or queues, a number showing current queue depth, and a throughput-over-time line chart. Tell Claude Code what the status values map to.
- Content or marketing dashboard: a traffic trend line chart, a bar chart for channel breakdown (organic, paid, direct), and a funnel showing visitor to signup to purchase. Tell Claude Code the event names your analytics tool uses.
- Client project dashboard: a card per client showing project status, last update date, and a progress indicator. Tell Claude Code the status values (active, on hold, delivered) and the key fields to display.
Connecting real data without starting over
The cleanest approach is to build the dashboard with hardcoded sample data first, make sure the layout and interactions are exactly right, and then do the data integration as its own step. This keeps two problems separate: does this display correctly, and does this data flow correctly.
When you are ready to integrate, tell Claude Code: 'Replace the hardcoded sampleData array with a fetch to [URL or Supabase table]. Handle the loading state with a spinner and the error state with a simple error message.' Claude Code writes the fetch, the loading skeleton, and the error boundary in one message. Review that the data shape from the real source matches the shape the charts expect - if it does not, one message fixing the transform is usually enough.
Deploying your dashboard as a live tool
A Claude Code dashboard is a React component - it deploys exactly like any other React app. The two fastest paths are Vercel (connect the repository, push, live in under two minutes) and a static export (useful if you want to share the dashboard as a file rather than a URL).
If the dashboard contains sensitive business data, add a simple authentication check before deploying to any public URL. Tell Claude Code: 'Add a password check on the index route - store the password in an environment variable called DASHBOARD_PASSWORD and return a 401 if the request does not include the correct value.' That is enough to keep the dashboard private without building a full auth system.
Short, practical drops on skills, MCP, agents, prompts, and more. No spam, unsubscribe anytime.
Frequently asked questions
What chart library will Claude Code use?
Claude Code typically reaches for Recharts or Chart.js for React dashboard builds - both are well-documented and work well in the Claude Code context. If you have a preference, specify it: 'Use Recharts for the charts.' If you do not specify, Claude Code will choose and document what it chose so you can adjust later.
Can I build a dashboard without a backend?
Yes. A dashboard can read from a static CSV, a hardcoded data array, or a third-party API. The only case that requires a backend is when you need to hide an API key from the browser - in that case, a simple server-side route is enough. Claude Code can build both the frontend dashboard and the simple API proxy in the same session.
How do I add authentication so only I can see the dashboard?
For a dashboard you share with a few people, the simplest approach is a password stored in an environment variable and checked server-side. For a dashboard with multiple users and different permissions, tell Claude Code to add Supabase Auth - it handles the login flow, session management, and route protection.
Can I deploy this as a live tool for a client?
Yes. A custom internal dashboard that shows a client their own real-time business numbers is a high-value deliverable. It connects to their data, runs on their domain, and shows exactly what they need. The Claude Code Profit Room covers how to scope, price, and deliver exactly this kind of build.
Last reviewed by David Iya on August 2, 2026
