Download AppThe people who use UniqueHuman hand us some of the most sensitive information they have: their symptoms, their health readings, their notes about the worst days. Health data is about the most sensitive category anyone can be trusted with, and the moment you hold it, being clever is exactly the temptation to resist.
The dangerous mistakes are the quiet ones
The hard part is that there is no single place to protect. One record does not sit in one spot. It rests in a database, it travels across a network to reach you, it gets read back by code that has to decide correctly, every single time, whose data this is, and it is watched by the analytics that tell us whether a feature is working. Each of those is a separate door, and a leak only needs one of them left open.
What makes it genuinely nerve-wracking is how quietly those doors fail. A misconfigured database does not throw an error, it just sits there, reachable, looking fine. An access check that hands back one row too many is indistinguishable from a correct one until the day someone notices the extra row belongs to a stranger. A replay tool meant to help engineers debug will cheerfully record a person typing their symptoms into a text box, and nothing about that looks broken. Nothing crashes. Nobody gets paged. The system keeps serving traffic while quietly doing the one thing it was never supposed to do.
So we make the boring choice, on purpose
Our answer is almost aggressively dull. Wherever we can, we reach for proven, managed building blocks instead of anything we would have to invent ourselves, and we save the creativity for the product. Your data lives in a managed Postgres database that is encrypted on disk, so the raw files mean nothing to anyone who somehow walks off with them, and it is kept off the public internet, reachable only from inside our own private network. Files you upload are encrypted on the server too. Everything travels over TLS, the same kind of encrypted connection as the padlock in your browser, and any plain, unencrypted request is bounced to the secure one before it reaches us. None of this is novel, and that is the whole point. A building block from a provider whose entire job is that one block will beat something we improvised under a deadline almost every time.
Your data, and no one else's
The part most likely to go wrong quietly is access, so we keep it strict and simple. Anything that reads your data goes through one shared sign-in check, the same check reused everywhere rather than reinvented feature by feature. Once it knows who you are, every read carries your user id down into the shared data-access methods, and those methods filter each query to that id, so a request only ever comes back with records that belong to the person who made it. You get your own data and nobody else's, and because that filter lives in the shared query methods rather than being re-typed on every route, there is one obvious place to keep it right. Passwords are never stored as passwords. We keep only a bcrypt hash, a one-way scramble, so even we cannot read the original.
We learn from usage, never from your content
Analytics is where health apps leak most easily, because understanding how people use the app is genuinely useful and the tooling is happy to capture far more than it should. So ours runs with the text you type masked, images masked, and screen replay switched off. We get to learn which features actually help without ever collecting the private details inside them.
Security is never finished, and we would rather say so
No system is ever done being secured, ours included. There is always a sharper edge to round off, an old assumption worth revisiting, a control that could be tighter. We treat each of those as a bug to fix on a schedule, not as an acceptable cost of doing business, and we would rather tell you that plainly than publish a glossy line about everything being perfectly safe. Anyone in health software who says their security is finished is either not looking hard enough or not being straight with you.
Underneath all of it is one idea. A safeguard that only holds because everyone remembered to be careful is not much of a safeguard. The real work is to push protection down into the foundation, the managed database, the forced encryption, the single path every request has to take, so that the safe thing is also the easy default and staying safe never depends on someone having a good day. Build on boring pieces. Stay honest about what is not done. And spend the cleverness on the problem we actually care about, which is helping people in pain.