Verified against Bolt.new · 2026-07-24
Turn a CSV export into an interactive, privacy-safe dashboard
A Bolt.new brief for a browser-only CSV dashboard that validates the file, skips and counts malformed rows instead of silently propagating NaN, and never transmits the parsed data anywhere.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Build a data dashboard in Bolt.new that turns a CSV file into interactive charts entirely in the browser — no upload to any server, no backend, since the data in this file is internal payroll data and should never leave the user's machine.
INPUT
The user drops or selects a CSV file with these columns: date, department, employee_count, total_hours, overtime_hours. Parse it client-side with a CSV parsing library, not a hand-rolled split(','), — real CSVs have quoted fields containing commas, and a naive split silently corrupts those rows instead of erroring on them.
DATA HANDLING RULES
Validate the file before charting anything: if a required column from the list above is missing, show a clear error naming exactly which column is missing rather than crashing or silently charting nothing. If a row has a malformed value in a numeric column — text where a number is expected, an empty cell — exclude that row from calculations and show a count of how many rows were skipped and why, rather than letting one bad row silently turn a sum into NaN across the whole dashboard. Assume the file could be large — around 15,000 rows is the realistic upper bound — so parse and aggregate in a way that doesn't freeze the browser tab; if the parsing library supports streaming or chunked parsing, use it rather than loading the whole file into one array before any processing starts.
CHARTS TO BUILD
1. total_hours over time as a line chart, bucketed by week.
2. A breakdown of total_hours by department as a bar chart, sorted descending, with a "show top 10, group the rest as Other" behavior if there are more than 10 distinct categories.
3. A summary row of stat cards above the charts: total total_hours, average per week, and the single highest week by value.
4. A raw data table below the charts, sortable by column, with the skipped-row count from above shown as a small note, not hidden.
INTERACTIVITY
Let the user filter by a date range and by one category value from department; every chart and stat card above must update together when a filter is applied — never let the line chart reflect the filter while the bar chart still shows the unfiltered set.
CONSTRAINTS
This is entirely client-side — no fetch call to any external endpoint with the parsed data, ever. If the file is dropped, do not persist it anywhere beyond the current browser session; a page reload can reasonably clear the dashboard and ask for the file again. clean and neutral, one accent blue, no illustrationsCustomize
Optional — swap in your own details for the highlighted parts above.
Why this works
Explicitly naming a real CSV parsing library instead of a naive split closes a specific corruption bug, not a stylistic preference. Real-world CSVs routinely contain quoted fields with embedded commas or newlines — an address field, a free-text note column — and a hand-rolled comma-split silently misaligns every column after the first quoted-comma field it hits, rather than throwing an error at the point of failure. That's a silent corruption bug invisible unless someone happens to check the exact row where it starts, and a vague "parse the CSV" instruction gives the model no reason to reach for a real parser over the simpler split it would otherwise default to. Skipping and counting malformed rows, instead of letting a bad value propagate, addresses how JavaScript's numeric coercion actually behaves: Number("") evaluates to 0 and Number("abc") evaluates to NaN, and once a single NaN enters a running sum, every downstream aggregate touching it becomes NaN too, silently. A dashboard showing "Total: NaN" is at least visibly broken and gets noticed immediately; a dashboard where one bad row out of fifteen thousand makes an average subtly wrong — because it was excluded inconsistently in one chart's calculation but not another's — produces a wrong-but-confident number, which is the more dangerous failure of the two. The client-side-only constraint is the actual reason to reach for a browser-only prototyping tool for this exact job in the first place. For genuinely sensitive data like payroll or health records, a dashboard that never transmits the parsed rows anywhere is a meaningfully different privacy posture than one that uploads the file to a backend for processing — and stating this as a hard constraint, not just an implementation preference, stops the model from reaching for a "simpler" server-side parsing route the moment the file size or chart complexity makes client-side processing feel harder to write, which would quietly violate the entire reason this approach was chosen.
Verified against
Bolt.new Bolt.new web app (StackBlitz WebContainers) · 2026-07-24
Changelog
- 2026-07-24 — Initial publish, verified against Bolt.new with client-only CSV parsing and an explicit skipped-row count.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
