Know Everything or Know Nothing
Pollify has to know who you are to keep a vote honest. Fyntra refuses to know who you are to keep your money private. Both are trying to earn the same thing.
- Published
- Reading time
- 3 min read
- Length
- 637 words
- Topics
- Privacy, Product design, Architecture
This month I released Pollify and ZX Player and started Fyntra. Two of them sit at opposite ends of one question. Pollify, a real-time polling app, works hard to know who you are. Fyntra, a money manager, works hard not to. They look like opposing philosophies. I think they’re one philosophy applied to two different promises.
Pollify Has to Know
A poll is a promise about counting: one person, one vote, and a result that reflects the people who took part. Keeping that promise means telling people apart. Pollify checks for repeat votes across five signals (account, email, device, session and IP) and lets a creator require sign-in, restrict voting to an email domain or list, or validate student IDs.
Each signal is weak on its own. Whole offices share an IP address, families share devices, and sessions are easy to reset. Together they make cheating expensive enough to keep a classroom poll or a club election honest. The product earns trust by knowing.
Knowing creates a second obligation. Pollify also offers anonymous ballots, which raises the question every voting system has to answer: anonymous to whom? Paper elections settled this long ago by keeping two separate records. The register knows that you voted. The ballot box knows what was voted. Neither knows both. A digital poll that wants to be fair and anonymous at once has to draw the same line through its data.
Fyntra Refuses to Know
Fyntra makes the opposite promise. Financial history is about as sensitive as data gets: where you shop, what you earn, who owes you money. The safest server for that data is one that never receives it.
So Fyntra works offline, without an account, and everything lives on the phone. Signing in with Google is optional and exists only for backups and moving between phones, and those backups go to a hidden app folder in the user’s own Google Drive. The small backend knows who signed in, so the app’s health can be monitored and abusive accounts blocked, but it never sees a single transaction. The product earns trust by not knowing.
ZX Player and the Undo Button
ZX Player, an offline video player for Android, sits on Fyntra’s side: no account, no ads, no uploads. But it adds a third kind of trust that has nothing to do with data collection. Deleting a file goes through Android’s own confirmation, and the file then waits thirty days in a Recycle Bin before it’s really gone.
That’s trust earned by forgiveness. A product that lets you take back a mistake is telling you it expects you to make some, and that it’s on your side when you do. Undo is one of the cheapest features to build and one of the largest in how safe it makes people feel.
Which Promise Does This Keep?
Put the three side by side and a pattern appears. Each starts from a promise: an honest count, private money, files you won’t lose by accident. Then it collects exactly the data that promise requires, and nothing else. Pollify’s promise needs identity, so it asks. Fyntra’s promise is broken by identity, so it doesn’t. ZX Player’s promise is about mistakes, so it remembers deletions, briefly.
The failure mode is the product that collects everything by default, just in case, with no promise that needs it. That isn’t a privacy-policy problem. It’s a design problem: data collected without a reason is risk without a return.
So the question worth asking before adding a field, a log line or a sign-in screen isn’t “could this be useful?” Almost anything could. It’s “which promise does this keep?” If there’s no answer, the field doesn’t go in.