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 performance at a pharmaceutical company. He regularly needs to see how each of his reps is doing against budget, then present that in person, often while traveling — using data that comes out of the company's existing sales system as an export file.
I'm not a developer. My background is marketing and communications. When he asked for something to help with this, the obvious answers were generic BI software or hiring someone to build a tool. Instead I used Claude Code, an AI coding assistant, and directed it in plain language to build a small custom web app myself.
The requirements weren't things I guessed at — they came out of an actual conversation with my uncle. The data is sensitive pharma sales figures, so the app had to run entirely locally in the browser: no server, no upload, works offline. The input is whatever Excel or CSV file he already exports, dragged into the app — not a live connection to the system, on purpose, so nothing sensitive ever leaves his laptop. The output had to be both a dashboard he could explore and a one-click PDF export formatted as slides, because he needed something to put up in a room, not just a screen to scroll through alone.
Below is roughly how I approached it with Claude Code, the actual instruction I'd give if I were starting over, and an honest read on where this stands right now — including the part that isn't tested yet.
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.