Personal safety

What personal safety apps are worth building?

The safest and most useful scope is planned, consent-based and time-limited. A check-in where the user chooses a contact and the contact knows what happens if the check-in is not confirmed. A checklist before a late journey. A location share that lasts for a set period and then ends on its own. A plan for a first meeting with someone from an online dating or social app. Each of these has a defined start, a defined end, and a person at the other end who can respond. That structure is what makes them honest.

What to avoid, in general, is the always-on, hidden or unverifiable tool. Ideas that try to detect danger from sensors, that run in the background without clear consent, or that promise a response from anyone are difficult to build well and easy to get wrong. A builder who starts with those ideas usually ends with a product that cannot show what it did. Start from what the user can see, start and switch off, and make every state visible.

Some personal safety ideas belong in a different category entirely: a medical alert, a fall detector, or a crisis service. Those carry clinical or regulatory questions that a general idea post cannot answer, and a builder should take them to the people who run such services before writing any code.

Who uses personal safety apps, and how do you reach them?

The users with the clearest need are lone workers, delivery and rideshare drivers, people walking home late, students in a new city, and people meeting someone in person for the first time after getting to know them online. Event organisers and care workers form a second group. They usually need a process with a named supervisor and a written procedure rather than a personal app, so a tool can support their process but should not replace it.

Reaching people needs care. Safety is a sensitive subject, and marketing that plays on fear is both unhelpful and likely to attract the wrong kind of attention. Let the first version be found through useful content about planning and check-ins, written for the person who has to decide what to do. Measure use by whether people set a check-in and keep it, not by how frightening the copy looks.

What makes a personal safety idea good?

• The user chooses the contact, the duration and the trigger. Nothing starts without a clear action from the person it is for.
• It says what it does not do. The app is not a call to emergency services unless it makes that call through a supported route, and its first screen says so before anyone relies on it.
• Data stays only as long as it is needed. A location shared for two hours does not need to be kept for two years.
• It fails visibly. If the network drops or a message does not send, the contact is told the check-in was not completed, rather than the system assuming all is well.
• It has been walked through its failure cases. The builder can list the situations where it fails, and each one has a visible state and a documented response.

Before posting an idea, write the one sentence that begins with “This does not”. If it is hard to write, the boundary of the idea is not yet clear enough to build.

What does a first version look like? A worked example

Hypothetical planned-walk check-in for one trusted contact. Before a journey, the user enters the destination, the expected arrival time and the contact. The app tells the contact when the walk starts and when the user taps “arrived”. If neither happens by the arrival time plus a grace period, the contact receives a message saying the check-in was not confirmed and asking them to try the user first. The app does not contact emergency services and does not share a live map.

Build a mobile-first web app. Inputs: destination (text), expected arrival time, grace period (default 15 minutes), and one contact’s phone number. On start, send one message to the contact with the destination and arrival time, after the user confirms that exact send. On “arrived”, send one confirmation. If neither happens by arrival time plus grace, send a message saying the check-in was not confirmed and asking the contact to try the user. Show on the first screen: “This app does not contact emergency services. In an emergency, call your local emergency number.” Store only the contact’s number and the times, and delete them after 24 hours.

Test by walking through the failures before any user does. Work through a dead battery, a message that fails to send, a user who taps “arrived” twice, and a contact who never reads the message. Each should produce a visible state, not silence. Only then test with a small group of people who make this journey regularly, and ask what they believed the app would do. Any gap between that belief and what it did is a design problem to fix before wider use.

What are the pitfalls specific to personal safety apps?

The central pitfall is a false sense of security. A user who believes an app will get help when it cannot may take a risk they would otherwise avoid, and may not call emergency services when they should. Every screen that involves a risk should say what the app does and does not do, and what to do in an emergency, in words that are easy to read under stress.

• Emergency services. Do not present the app as a way to reach police, ambulance or fire services unless it connects through a supported official route in the user’s country, verified in advance. Otherwise, direct people to the local emergency number on the first screen.
• Failure nobody can see. Notifications are delayed, batteries die and networks drop. An app that fails silently teaches people to trust a process that did not run.
• Tracking used for control. Location sharing and check-ins are also used by controlling partners and abusers to monitor someone. Make any sharing visible to the person being shared, time-limited and easy to revoke. Do not build covert or hidden tracking, and do not design features whose main use would be watching another adult.
• Sensitive data about vulnerable people. Location history, routes and emergency contacts are sensitive. Keep the minimum, delete it on a fixed schedule, and never sell or share it.
• The worst case, tested. Ask what happens if a contact panics, if the user is overheard using the app, or if a message reveals a location to someone who should not see it. A design that has no answer to those questions is not ready.

Posts on this board are published without review, so the board does not vouch for any idea in this category. A builder who takes one of these ideas on should arrange a security and privacy review before the tool holds anyone’s location or contacts, and should not treat the absence of a warning on the board as approval.

Where to start: post a narrow idea

Nothing in this category was on the board when this page was written. If you have an idea, post it with the person it serves, the single situation it covers and a sentence on what it does not do. A narrow post with its limits written in gives a builder more to work with than a broad one that promises protection, and because posts are permanent, those limits should be right the first time.

Before anyone builds it, read how to validate an app idea and talk to people who live with the situation, not to people who would like the idea in principle. Keep the first version to one planned event, one contact and one clear end. How to scope an MVP helps cut the rest, and anything that runs without the user’s action should be the first thing cut.