I'm not a developer. I used Claude Code to build my uncle a local sales dashboard with one-click PDF export.
My uncle manages sales reps at a pharmaceutical company. He needs to see how each one is doing against budget, and then present that in a room, often while travelling.
I am not a developer — my background is marketing. The obvious answers were generic BI software, or paying somebody to build a tool. Instead I directed Claude Code in plain language and built a small web app myself.
The requirements came out of an actual conversation with him, not from me guessing. The figures are sensitive, so the app runs entirely in the browser: no server, no upload, works offline. He drags in the Excel export he already produces — deliberately not a live connection to the system, so nothing sensitive leaves his laptop.
And the output is not only a dashboard. One click turns it into a PDF laid out as slides, because he needed something to put up in front of people, not a screen to scroll through alone.
Steps
- 1
Started with a real conversation, not a prompt
Before touching Claude Code, I sat down with my uncle and worked out what he actually needed: sensitive data that couldn't leave his laptop, an export file he already had rather than a live system connection, and something built for standing in a room, not just for him alone at a screen.
- 2
Set the hard constraint up front
I told Claude Code the app had to run entirely in the browser, with no server and no upload, so it works offline and nothing sensitive gets transmitted anywhere. That one constraint shaped every decision that followed.
- 3
Built in tolerance for messy real-world exports
Export files from real systems rarely use the exact column names you'd expect. I had Claude Code add a synonym-matching layer so small naming differences in the file don't silently break the import.
- 4
Asked for two outputs from one file
The dashboard needed to be interactive for exploring the numbers, and there also needed to be a one-click PDF export formatted as presentation slides, because my uncle needed something to show in a room while traveling, not just a screen to scroll through.
- 5
Tested against realistic sample data, not yet the real thing
The app works end-to-end against sample data shaped like his real export. It has not been run against his actual first export yet — that's the next step, and I'm stating that plainly instead of implying it's already handling real production data.
- 6
Kept myself in the loop for the next round
Since the column-matching only knows the variants I've already taught it, a genuinely new export format will need me to go back to Claude Code and update it. This only stays maintainable as long as I'm available to do that.
I need you to build a small web app that runs entirely in the browser — no server, no database, no external calls. It needs to work completely offline once loaded, because the data going through it is sensitive (sales performance figures) and none of it should ever leave the laptop it's running on.
Here's what it needs to do:
1. Let the user drag and drop an Excel or CSV file onto the page. This file is exported by hand from an existing sales system — there is no live connection to that system, and there shouldn't be one. Assume the file has columns for sales rep name, actual sales figures, and budget/target figures, but don't assume the column headers match exactly. Build a synonym-matching layer that recognizes common naming variants — for example, "Rep," "Sales Rep," and "Agent" should all map to the same field, and "Budget," "Target," and "Quota" should all map to the same field. If a column can't be matched, tell the user clearly instead of silently failing or guessing.
2. Once the file is loaded, show an interactive dashboard comparing each rep's actual performance against their budget — who's over, who's under, and by how much, sortable and readable at a glance.
3. Add a one-click "Export to PDF" button that turns the same data into a set of presentation-style slides, not just a printout of the dashboard. It needs to look like something you'd put up in a meeting room, not a spreadsheet screenshot.
4. Everything happens client-side. No upload, no backend, no accounts, no data leaving the browser.
Build this as a working app, then let's test it together against a sample file shaped like a real export before I try it on the actual data.Where this breaks
The app is built and works end-to-end, but only against realistic sample data shaped like the real export — it has not yet been run against my uncle's actual first export, and that's still the real test ahead. The synonym-matching only recognizes the column-name variants I already taught it, so a genuinely different export format will fail to map correctly, and since I'm not a developer, fixing that means going back to Claude Code rather than my uncle patching it himself — this only stays maintainable as long as I'm around to update it. There's also no backup or version history anywhere, because running entirely in the browser with no server means if he overwrites or loses the exported file, nothing else has a copy of that data.
Did this work for you?
Sign in to report a result. This is the number everyone reads first.