HN Explorer

Ask HN: How do founders demo real product without exposing sensitive data?

5 points by legitimate_key ↗ HN
Pitching soon and want to show the real thing, not a sanitized environment. How do you handle sensitive during live demos?

The problem: investors want to see your actual product working with real data, but showing real dashboards means exposing credentials, API keys, client data, or internal systems on a shared screen.

The usual options all have problems: - Demo environment with fake data → looks staged, kills credibility - Real product with real data → security risk, one screenshot away from an incident - Pre-recorded walkthrough → can't answer specific questions or show interactivity

Curious how others handle this. Do you just accept the risk? Build sophisticated demo infrastructure? Something else entirely?

9 comments

[ 205 ms ] story [ 958 ms ] thread
gnatman
Surely real product with fake data is the answer. Fake data doesn’t necessarily mean “silly” data e.g. names like Larry Llama or myfaketestwebsite.com. There’s no reason why your real product running on sandboxed data should hurt your credibility.
legitimate_key
I thought this too initially - "just make the fake data look professional."

Where it broke down for me: investors with technical backgrounds would ask edge case questions ("show me how this handles 10K records" or "what does error handling look like with real load?"). The fake environment couldn't simulate that complexity authentically.

The other issue was muscle memory. When I'm demoing something I use daily, I'm fast and fluent. In a fake environment, I'd hesitate or click wrong because it's not my real workflow. Investors noticed.

Have you found ways around those issues?

efortis
I’ve used (and wrote) https://mockaton.com for this. It has a browser extension, which downloads all API responses in your flow.

then you can run mockaton with those mocks. you’ll manually have to anonymize sensitive parts though.

also, you can compile your Frontend(s) and copy their assets, so yo can deploy a standalone demo server. see the last section of: https://mockaton.com/motivation

mocks don’t have to be fully static, it supports function mocks, which are http handlers.

for demoing, the dashboard has a feature for bulk selecting mocks by a comment tag.

legitimate_key
Thanks for the Mockaton suggestion! I like the API mocking approach - that handles the backend data cleanly.

The challenge I kept running into was the frontend side during live screen shares. Even with mocked APIs, I'd have credentials visible in browser tabs, notifications popping up with client names, or sidebar elements showing sensitive info.

Did you find Mockaton solved the full screen-share exposure problem, or did you combine it with other approaches?

rekabis
At my last job they had an entire section of the product - hidden behind feature flags and enableable only in development - whose sole purpose was to generate dummy content for the different sections of the product. When I left, they were extending it with AI integration to have it generate more realistic data. The overall program - when in prod - contained massive amounts of PPI/PII, so we needed a way to generate massive amounts of realistic-looking dummy data to stress test it while in dev.
legitimate_key
This is interesting.

How much overhead did that add to your development workflow? I'm curious if building and maintaining that parallel demo infrastructure became its own project, or if it stayed lightweight.

Also, did you use this for investor demos specifically, or more for development/QA?

rekabis
It had almost no workflow overhead. Remember - a data generator has essentially no overhead aside from any rules-based constraint on the data (how realistic it should be, what patterns it needs to have), and the format in which this data is stored (invariably a database). It had no interactions with any part of the main application, the only thing it touched was the database.

This let it be “simple” in terms of how it generated content, with it being “complicated” only in terms of what content it needed to create and its interconnections. Because patient profiles were simple to define, but were completely different than, say, the medications they were prescribed or the appointments that had been scheduled. Or the connections between appointments and prescriptions.

So yeah, generating data is simple, defining what data to be generated and in what patterns was a lot more difficult. Sometimes things that should be related could only be generated in isolation from each other because of how that part of the generation tooling was assembled.

This was almost 100% used by developers and QA. Outside demos had a special DB used by sales with much more consistent data, albeit much smaller. The generator was meant to create _large_ data sets, just not very _pretty_ data sets.

skeam
What's the product? You can create a demo based on true but anonymized data, like a movie based on a true story, and let the people in the room know about it.