Why I Added a Privacy Notice to My App

Several days ago, my company held a legal training session for all employees about personal data protection.

At first, I expected it to be a purely legal session. I thought it would mostly cover rules, definitions, and compliance terms that sound important but feel far away from day to day product work. But the session turned out to be much more practical than I expected. The speaker explained what counts as personal data, how it should be collected and processed, what a personal data violation looks like in real life, and what we should do as developers to protect user information. It was the kind of training that makes you rethink the products you build.

One topic in particular stayed with me: privacy notices.

For many users, a privacy notice is the first place they look when they want to know whether an app is safe to use. For us developers, it is also a design decision, a trust decision, and a technical decision. It is where we explain, in plain language, what data the app collects, why we collect it, where it is stored, who can access it, and how long it stays in the system. A good privacy notice is not written to hide information. It is written to reveal it clearly.

That made me think about my own app, Milk Tracker.

I built it as a simple tool to help log breast pumping sessions and track milk supply. At first, I treated it like a small personal project. I thought that because the app was simple, the privacy risk would also be simple. But the training made me realize that simple apps can still handle sensitive data. Even a lightweight app can make users hesitate if they do not know what happens to their information.

That realization became very personal when one of my colleagues refused to use my app.

She was not being dramatic. She was being careful. Her concern was straightforward: she did not want her personal data to be misused. That reaction stayed with me because it showed something I had underestimated. Trust is not automatic, even for a small app built by one person. If users cannot see how their data is handled, they will assume the worst. And honestly, that is a fair assumption.

Around the same time, I remembered the news about Flo, a popular women’s health app that faced scrutiny over how it handled sensitive health data. It was another reminder that privacy problems do not only happen in large platforms. They can happen in products that users trust deeply, especially when the data involved is intimate or health related. Once that trust breaks, it is very hard to repair.

So I went back to my own app and looked at it from a different angle.

What information does it collect?
How is guest data handled?
What happens if someone signs in with Google?
Where is the data stored?
Does the app use trackers?
Does it send anything to third parties?
How can a user delete their data?

Those were the questions I started answering one by one.

I kept the first version of the privacy notice intentionally simple. I am an indie developer, not a large company with a legal team behind me, so I did not try to write a heavy policy full of complicated legal terms or claim full GDPR compliance from day one. But I still tried to cover every important aspect as clearly as possible. I wanted the notice to be honest, useful, and specific enough that a real person could understand it.

So I documented the things that matter most.

I explained that users can use the app as a guest without sharing personal details, or sign in with Google if they want to save data permanently. I explained that guest data is temporary and is deleted after inactivity. I explained that the app stores pumping data, basic profile data when sign in is used, and optional AI context only when the user provides it. I also wrote down where the data lives, which services process it, and how optional features like AI summaries and notifications work.

That process taught me something important: privacy is not just about compliance. It is also about architecture.

The moment you decide to use guest accounts, you need to think about account recovery and data retention. The moment you let users sign in with Google, you need to understand what identity data is actually stored. The moment you add optional AI features, you need to think about what is sent to the model provider, what should be de-identified, and how to make that opt in instead of default. The moment you rely on a backend like Firebase, you need to understand what data is stored there, where it is hosted, and how access is protected.

In other words, privacy is not a page you add at the end. It is part of how the product is built.

I think that is why the training affected me so much. It connected the legal side of personal data protection with the technical side of app development in a very direct way. It made me realize that users are not only trusting the interface. They are trusting the whole system behind it.

And once I saw my own app through that lens, writing the privacy notice became more than a compliance task. It became a way to respect the people who might use it.

Even if the app is small. Even if the developer is just one person. Even if the first version is not perfect yet.

Because in the end, privacy is part of product quality.