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

1. If Frontend is directly fetching from a third-party API. Maybe, you could add an env var with the base URL, so it points to the mock server.

2. If it’s a third-party auth service

2a. If the auth service sets a cookie with a JWT, you could inject that cookie with Mockaton like this: https://github.com/ericfortis/mockaton/blob/354d97d6ea42088b...

2b. If it doesn't set a cookie (some SSO providers set it in `sessionStorage`), and assuming it’s a React app with an <AuthProvider>, you might need to refactor the entry component (<App/>) so you can bypass it. e.g.:

  SKIP_AUTH // env var
   ? <MyApp/> 
   : <AuthProvider><MyApp/></AuthProvider>

  function useUser() {
    const context = useContext(AuthContext)

    if (!context) 
      return {
       id_token: 'aa',
       profile: { name: 'John' }
      }

    return {
      id_token: context.id_token ?? '',
      profile: context.profile ?? {},
    } 
  }

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.

> "what does error handling look like with real load?"*

I find it hard to believe that anyone is making an investment decision off of this question, but how would you demo this with a real customer anyway? Intentionally introduce a bug so that you can show them how errors are handled? Wouldn't the best course of action here be to just describe the error handling?