On this page
Data you do not use is not an asset. It is something you have to secure, explain in a policy, hand over when asked, and delete when told — with no corresponding benefit. Most small applications store roughly twice what they use, and nearly all of the excess arrived by accident rather than by decision.
Four questions, applied to each field, usually delete half a schema.
The four questions
| Question | If the answer is no |
|---|---|
| What decision does this field change? | stop collecting it |
| Would I miss it if it vanished tonight? | stop keeping it |
| Does it identify a person? | it needs a reason and a retention period |
| Do I know how to delete it on request? | you have an obligation you cannot meet |
The first is the one that does the work. "It might be useful later" is not an answer — it is the sentence that produced the field you are now looking at.
What gets stored without anyone deciding?
Three things, in every project I have looked at.
Full IP addresses in logs. Request logging is on by default nearly everywhere, and an IP address is personal data. You did not choose to collect it, you chose a platform, and it came along.
Whatever the payment provider sent back. The response object is convenient, so it gets saved whole. Inside it: name, address, card metadata, sometimes more. You needed the transaction id.
Form submissions, forever. A contact form writes a row. The message was answered in March. The row is still there, with whatever the person typed into it, which on a support form is frequently more than you would have asked for.
None of those is negligence. All three are defaults.
The whole list
67 tools, what each costs and when you actually need it. Updated twice a year.
What does "keep the reference, not the copy" mean?
That the provider holding the data is better placed to hold it than you are.
Your payment processor is already obliged to store transaction details properly, under far more scrutiny than you are. If you keep the transaction id and look up the rest when you need it, you have lost nothing you use and removed an entire category of thing you are responsible for.
The same applies to email delivery, file storage, and anything else where a service already has the record. The question to ask of each copy: if this were deleted from my side right now, could I still do my job? Usually yes, by asking the service.
What about the data you actually need?
Give it a retention period, written down, and then actually apply it.
A policy saying "we keep this as long as necessary" is not a retention period, it is a sentence. A retention period is a number and a job that enforces it.
| Data | A defensible period |
|---|---|
| Request logs with IPs | days, not months |
| Contact form submissions | until resolved, plus a short tail |
| Order records | as long as tax rules require |
| Email list | until they unsubscribe, then gone |
The order row is the one people get backwards: that is the data you are required to keep, and the instinct to minimise can go too far. Knowing which is which is most of this.
Can you answer a deletion request?
This is the practical test, and it is more revealing than any audit.
Someone emails and asks you to delete everything you hold about them. Can you? Within a month, completely, including the copy in your email provider, the row in your form submissions, and the entry in whatever you exported to a spreadsheet in August?
If the honest answer is "I would have to go looking", the schema is too wide. Every place the data went is a place you now have to remember under time pressure.
Does this apply to a site with no accounts?
Yes, and it is easier.
A static site with an email form stores one thing: addresses. That is a clean position to be in, and it is worth protecting rather than drifting away from. Each new feature that stores something is a decision to leave that position, and it should feel like one.
Privacy-friendly analytics matters here for the same reason — the options that do not identify people are not a compromise, they are the ones that keep this question simple.
Where to start
Open your schema and read it out loud, field by field, asking the first question. It takes twenty minutes on a small application and it is uncomfortable in a useful way.
What is it really storing is the prompt for doing this against a real codebase, and what can a stranger read from your app? is the complementary check on who can reach it.
Where this came from
Method, not measurement. The three defaults listed above are the ones that show up consistently; the four questions are the ones that produce deletions rather than discussion. No percentages are given because the honest ones would be anecdote.
Claude Code Operator covers the data side of building with an agent, which generates schemas enthusiastically and prunes them never.
Tools in this piece
| Tool | What it does | Price |
|---|---|---|
| Supabase | Database, accounts and file storage in one, with no backend work. | Free tier |
| Vercel | Hosting. Puts a project live on a real address with one command. | Free tier |
| Stripe | Payments and subscriptions. The standard, and integrating it is a matter of asking. | Free, percentage per sale |
| Resend | Transactional email that actually arrives. | Free tier |
| Plausible | Simple, privacy-friendly visitor stats with no cookie banner. | ~€9/mo |
Every tool has its own page with the price, who should skip it and what to check before paying. Some links are affiliate links.
Questions people ask
Why is storing extra data a problem?
Because every field you keep is something you have to secure, explain, and hand over or delete on request. Data you do not use has no upside and all of the obligations, which makes it a liability rather than an asset.
What does an app store that its owner forgets about?
Usually three things: full IP addresses in request logs, whatever the payment provider sends back and gets saved wholesale, and the contents of form submissions kept long after they were acted on.
How do you decide whether to keep a field?
Ask what decision it changes. If nobody can name a question the field answers, it does not need collecting. 'It might be useful later' is how schemas grow and is almost never true.
Do you need a privacy policy for a small site?
If you collect anything that identifies a person — an email address counts — then yes. It is also easier to write once you have actually listed what you store, which most people do in the wrong order.
Is it safer to let the payment provider hold the data?
Generally yes. The provider already has to store the payment details securely, so keeping only the reference to the transaction rather than a copy of its contents reduces what you are responsible for without losing anything you use.
What about analytics data?
Privacy-friendly analytics avoids most of this by not storing anything that identifies a person. If you are using something that does, you have taken on an obligation in exchange for reports you are probably not reading.