Collect Founder Demographics Without Storing PII

California's FIP-VCC reporting model creates a hard requirement: produce required outcomes while reducing the risk of re-identifying any individual founder. That means your data model matters as much as your filing workflow.

Why aggregate-only design is safer

If your system stores per-founder answers, every export and query can become a privacy risk. Aggregate-only design changes that:

• You store counters by category, not person-level records.
• You avoid creating a table that can be linked back to a founder.
• You keep reporting outputs aligned with anonymized filing expectations.

Practical implementation steps

1. Capture investment-level company fields required for reporting.
2. Use invitation state tracking only (sent, redeemed, expired), without response payload storage.
3. Increment aggregate counters when submissions are completed.
4. Restrict logs and analytics so sensitive payloads are never persisted.
5. Generate report outputs from aggregate counters only.

A useful internal test

Ask this before launch: "If one founder asked for a copy of their submission, could we reconstruct a person-level response?"
If the answer is yes, the system is not aggregate-only.

Final note

This post is product and engineering guidance, not legal advice. Work with counsel for interpretation of law and filing obligations.