Start with questions, then choose the metrics
A useful dashboard answers a small set of questions. A subscription business might ask whether revenue is growing and which customers are leaving. An operations team might need to know which orders are late and who should act next.
Define each metric before asking for a chart: its source, time range, calculation, currency or unit, and refresh frequency. “Monthly recurring revenue” and “payments collected this month” can be very different numbers. The interface should make that distinction clear.
A prompt you can adapt
Specify the records and actions as well as the headline numbers. This example creates a frontend starting point; the illustrative values still need to be replaced with a verified data source.
Build a responsive SaaS dashboard for a subscription business. Show MRR, active customers, and cancellations, with a date-range selector. Add a monthly revenue chart and a searchable customer table with status filters. Include loading, empty, and error states. Use clearly labeled sample data for the first preview. Keep the metric calculations separate from the presentation so I can connect a real API later.Open the app builder
Give charts and tables different jobs
Use charts to show a trend or comparison and tables to inspect individual records. Keep labels visible, show units, and make date ranges explicit. Do not rely on color alone to communicate whether a metric increased or decreased.
On a phone, arrange summary metrics in a readable stack and decide which table columns matter most. Test long customer names, zero values, missing data, and unusually large numbers. A layout that works with six sample records may behave differently with real data.
Reference documentation
How do I connect a dashboard to real data?
You can ask the builder for an API integration and inspect the generated source in Code. Credentials belong on the server. A database or external service needs its own configuration and access rules; a frontend preview alone does not provide them.
Describe the saved records and sign-in rules in chat. BrainHalf can prepare a supported managed Workers backend and an isolated database. Check that records survive reloads and that a separate account cannot read them. Keep an external data source’s credentials on the server and verify its permissions separately.
Check the numbers as carefully as the design
Compare every displayed metric with a small, known dataset. Test the same date filter across cards, charts, and tables, including boundaries such as the first day of a month.
- Label sample data and remove it before connecting a live workflow.
- Check how timestamps and time zones affect reporting periods.
- Show a helpful empty state when no records match the filters.
- Test loading failures, retry actions, and access restrictions.
- Verify the published app against its actual API and production database.