The question I kept asking myself while building Kin, and why the answer is more complicated than it sounds.
TL;DR: Most safety apps solve a safety problem by handing you a surveillance one. Four mechanics create that feeling. Continuous streams, asymmetric visibility, punished silence, permanent records. None are accidental. They are design choices made in service of a data business. Building against them is possible. It is also the hardest product decision you make repeatedly.
I've been sitting with this question for a while. Not as a thought experiment, but as a design constraint.
When I started building Kin, I kept describing it as a "privacy-first check-in app." People nodded. It sounded right. But one evening I asked myself the harder version of the question: is that actually possible? Can you build something that helps people stay safe without creating the infrastructure for surveillance? Or is that a contradiction baked into the idea itself?
I don't think it is. But the answer is more nuanced than most safety apps, including the well-intentioned ones, are willing to admit.
The Feeling Has a Name
Most of us have felt it. You open a location-sharing app and you can see someone's exact coordinates, their battery percentage, when they last moved, and whether they're at home or in transit. It's useful. It's also unsettling, even when you're the one being watched, even when you chose to be watched.
That feeling isn't irrational. It's a signal.
What you're experiencing is the difference between being safe and being observed. They're not the same thing. One is about your wellbeing. The other is about data: who holds it, when they can access it, and whether your silence is treated as information. The big safety apps conflate these two things by design, because if observation is the product, conflation is the business model.
Where the Surveillance Feeling Actually Comes From
I spent a long time trying to identify exactly what triggers it. It isn't any single feature. It's four mechanics working together, and each one compounds the others.
The first is the continuous stream. You are being watched even when nothing is wrong. The app doesn't wait for you to need help; it collects your location constantly, just in case. The cost of that "just in case" is that you're never not being tracked.[1]
The second is asymmetric visibility. The person watching can look at any time. The person being watched has no control over when that happens. This is the structural dynamic of surveillance: not the content, but the power imbalance.[2]
The third is what I'd call punished silence, and it bothers me more than the others. In most safety apps, if you don't respond, something escalates: an alert fires, your location is auto-shared, someone is notified. Silence is treated as a problem. But silence isn't distress. Sometimes people just don't want to respond. Building a consequence into non-response is coercive by design.
The fourth is permanent records. Your location history exists somewhere on a server, often in a jurisdiction you've never thought about, as a log of where you've been. That log can be sold, subpoenaed, or leaked.[3][4][5]
None of these are necessary for safety. They're choices, made in service of a data business rather than a safety mission.
The Honest Tension
Here's where I have to be fair to the harder question.
You can design an app that avoids all four of those mechanics. That's what I'm trying to do with Kin. No background tracking. No continuous stream. No auto-escalation on silence. No location logs.
But the technology being private doesn't fully solve the problem. Because the surveillance feeling doesn't only come from the app. It also comes from the relationship. A controlling partner or an anxious parent can use even the most restrained check-in system as a tool for pressure. The app can't fix a power imbalance between people. No code can.[6][7]
What the app can do is refuse to be complicit in it. That's a real distinction.
What "Private" Actually Means in This Context
The word "private" gets applied too loosely to safety tech. It usually means one of two things: the data is encrypted, so third parties can't read it, or the company doesn't sell your data, so you're not the product. Both matter. Neither is sufficient.
The more useful definition, the one I'm designing toward, is this: privacy is consent and control over information flow. Not zero information. Consented, intentional, ephemeral information.[8]
Think about what happens when you call someone to say you landed safely. That's not a privacy violation. They now know where you are. But you chose to share it, they can't access that information at any other time, it doesn't persist anywhere, and no third party was in the room.
Kin is trying to be the digital equivalent of that phone call. A signal you choose to send, to people you've chosen to trust, that disappears after it's received. The content of your check-in is encrypted end-to-end and purged once delivered. Minimal routing data, like sender, recipient, and timestamp, is held briefly for delivery, then deleted. Not zero information, but consented, bounded, intentional information.
Kin uses your phone number for sign-up, the same way Signal, WhatsApp, and Telegram do, to confirm you're a real person and prevent spam. The number is verified through a standard auth provider; we don't store it in our own database, we don't link it to your check-ins, and it isn't shared.
That's a completely different thing from surveillance. The distinction just requires you to build it in from the start, not bolt it on as a privacy policy after the architecture is already extractive.
Why This Is Actually Hard to Build
The honest answer is that most apps don't make these choices because the opposite choices are easier, technically and commercially.
Continuous location streams are simpler to implement than event-driven signals. Background data collection is cheaper than building explicit consent flows. Location history is valuable to advertisers. Escalation-on-silence creates engagement that keeps people opening the app.[9]
Every surveillance mechanic I described above is also a growth mechanic. That's why they're so common. Not because the founders were malicious, but because the incentives pointed in one direction and nobody pushed back hard enough.
Building against those incentives, and staying there as the product scales, is a daily decision, not a one-time architecture choice. The pressure to add just one more feature (read receipts, location history, push-on-silence) will be constant. Staying minimal is the hardest product decision you make repeatedly.
So, Is It Possible?
Yes. But only if you're willing to accept what you're giving up.
You're giving up the convenience of always knowing. You're giving up the data exhaust that makes the business model easy. You're giving up the engagement loops that keep users coming back involuntarily.
What you're left with is something that only works if people want to use it. A tool that earns presence rather than harvesting it. Something people pick up because they feel like it, because they want to reach out, because they care about someone and want them to know it, not because an algorithm decided it was time.
That's a harder product to build. It's also the only version I'm interested in making.