Ask Your Dev Team about data privacy
If your product handles user data, your developer should be talking about privacy before you ask. Learn what to expect around regulations, PII, and data protection.
If your product collects user data, and most do, privacy isn’t optional. It’s a liability.
The problem isn’t that privacy is complicated. It’s that too many developers treat it as someone else’s job. They build the feature, ship the form, store the data, and never once ask, “are we allowed to do this?”
Your developer should bring it up first
Here’s the baseline: if your developer doesn’t mention data privacy and your product handles any kind of user information, that’s a concern. Not a yellow flag. A concern.
A good developer will proactively identify which regulations apply to your business. That might be GDPR if you serve users in Europe, HIPAA if you’re in healthcare, CCPA if you have California users, or something else entirely. The point isn’t that you need to know the acronyms. It’s that your developer should.
If they wait for you to ask, they’re treating privacy as an afterthought. And privacy as an afterthought is how companies end up in the news.
What to ask
You don’t need to become a compliance expert. You need to ask the right questions:
- “How do you handle personally identifiable information (PII)?” PII is anything that can identify a user: name, email, address, phone number, payment details. Your developer should have a clear answer for how this data is collected, processed, and protected.
- “Is our data encrypted at rest and in transit?” In transit means data is protected while it’s moving between systems. At rest means it’s protected where it’s stored. Both matter. If your developer hesitates on this one, dig deeper.
- “What’s our data retention policy?” How long do you keep user data? Forever isn’t an answer. Your developer should help you define how long data is stored and when it gets deleted.
- “Can a user request their data be deleted?” Under most modern privacy regulations, the answer needs to be yes. Your developer should be able to explain how that works technically.
- “What happens in a data breach?” There should be a plan. Not a shrug.
Privacy by default
The best developers build with privacy as a default, not a feature you bolt on later. That means:
- Collecting only the data you actually need
- Storing it securely from day one
- Building deletion and export capabilities into the system, not retrofitting them when a regulation forces your hand
- Logging access to sensitive data so you have an audit trail
This isn’t about being paranoid. It’s about being responsible with the trust your users place in your product.
Know what applies to you
You don’t need to read the full text of GDPR. But you do need a developer who can tell you, plainly, what regulations your product falls under and what that means for how they build it. If they can’t do that, you’re taking on risk you don’t fully understand.
Expect better. Build better.