Other People's Data
The Moment the Stakes Change
Everything before this module was about you. That changes the moment a real person types their name, email or anything else into your app. You are now holding something on their behalf, and they have no way to check whether you are doing it competently. They are trusting you by default, simply because the form looked normal. That is worth sitting with for a second. It is easy to keep treating a prototype as a personal project after it stops being one. This is not a reason to avoid building. It is a reason to know what you are taking on before the first person hands you something, rather than afterwards.
- Users trust you by default because the form looked ordinary
- They have no way to see how carefully their data is handled
- A prototype stops being a personal project the moment real data arrives
- Know what you are taking on before the first submission, not after
The Best Protection Is Not Collecting It
The single most effective safety measure available to you costs nothing and takes ten minutes: delete fields. Every piece of information you do not collect is one you cannot lose, cannot leak and cannot be asked to account for. Go through your form and ask of each field whether you will genuinely use it, now, for something specific. Date of birth "for demographics" you will never look at. A full postal address for a service delivered by email. A phone number you will never ring. These are pure liability with no benefit. This is not minimalism for its own sake. Data you do not hold is the only data that is perfectly safe, and it is the one protection that never fails.
- Every field you remove is a risk that disappears entirely
- Ask of each field: will I use this, specifically, and soon?
- "Might be useful later" is not a reason to hold personal information
- Data you never collected is the only data that cannot leak
Things You Should Not Be Storing Yet
Some categories are not appropriate for a prototype built by one person. Card numbers: never store these. Use a payment provider's own checkout, so the details never reach you. Passwords: never invent your own sign-in. Use the sign-in built into the platform you are on, because doing it properly is genuinely difficult and doing it badly is invisible. Health information, identity documents, anything about children: these carry specific legal duties and are not a first project. The honest framing is not that you are incapable. It is that these areas punish small mistakes severely, and give you no signal that you made one until it is public.
- Card details: never touch them — redirect to a payment provider
- Passwords: use the platform's sign-in, never write your own
- Health data, ID documents and children's data carry specific legal duties
- These areas punish small mistakes and give no warning that you made one
Why "I'll Fix It Later" Is How Leaks Happen
Every leak has the same story behind it. Something was left open during building, because that was convenient. It was going to be tightened before anyone used it. Then people started using it, nothing appeared to be wrong, and the temporary state became permanent. There was nothing to remind anyone. Insecure software does not look insecure. From the outside it looks identical to secure software, which is exactly why "later" never arrives. The practical fix is not more discipline, it is ordering. Do the tightening before you share the link, not after. Write down anything you deliberately left loose while building, and treat that list as a gate rather than a wish.
- Insecure and secure look identical from the outside — nothing prompts you
- Temporary shortcuts become permanent because they never announce themselves
- Keep a written list of anything you left open on purpose
- Treat that list as a gate before sharing the link, not a task for later
Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.