The Safest Place to Put It Is Nowhere

We built a free tool that accepts uploaded documents from strangers on the internet. The most useful architectural decision we made was to keep none of them.

The upload path is in-memory only. Nothing written to a database, to object storage, or to a temp file. Extracted text goes to a model provider solely to locate fields, and then it is gone. Logs carry the byte count and the outcome — never content. Metrics are numeric-only.

That last detail matters more than it reads. It is a rule enforced in code, not a norm enforced in code review. Norms decay under deadline pressure. The distinction shows up at 2am, six months from now, when someone adds a debug log to chase a production issue and reaches for the nearest variable.

The reasoning was not purity, and it was not really privacy in the abstract. It was that every stored document is a liability with an ongoing maintenance cost:

• a retention policy somebody has to define
• a deletion path somebody has to build and test
• a breach surface that grows monotonically
• a subject-access request somebody has to service
• eventually, a conversation with a user you would rather not be having

Storing nothing removes all of it at once, permanently, with no ongoing effort.

It is genuinely less impressive on an architecture diagram. There is no interesting encryption story, no key rotation design, no clever access-control model — because there is nothing to protect.

It is also dramatically easier to defend, and it stays easy as the system grows.

The default I would offer anyone building something similar: for data you have no concrete product reason to keep, the answer is not "encrypt it properly". The answer is "do not have it". Encryption is what you do when you have decided to carry the liability. The cheaper move is usually to decline it.