A personal safety platform, where discovery is the harm
An application for people at risk from somebody they live with, and the platform behind it that carries an alarm to responders. Almost every decision here runs opposite to how consumer software is normally built.
- Defences point at the device, not away from it
- No credential to steal
- Alarm commits locally before any network
- Client not named, product not described
Why this page does not describe the product
This is the only case study on this site that deliberately withholds what was built.
The application protects people from somebody who lives with them. Its most important protection is that it does not look like what it is, and that protection lasts exactly as long as nobody knows to look for it.
Perpetrators of domestic abuse monitor phones. It is one of the most common features of coercive control, and material published about safety tools is read by precisely the people those tools exist to defeat. A case study describing the disguise, the trigger, or where things are kept would be a checklist read by the wrong person.
So there are no screenshots, no product name, no client name, and nothing here that would help somebody identify this application on another person's phone. What follows is the engineering reasoning.
- Client
- A personal safety provider. Not named, for reasons set out here.
- Sector
- Public safety and social impact
- Users
- People at risk, and the responders dispatched to them
- Our scope
- Mobile applications on both platforms, backend services, responder dashboard, alarm and evidence handling, cloud infrastructure
The one fact that shaped everything
The person the user needs protecting from is holding the phone.
Almost every security assumption in consumer software runs the other way. The attacker is remote, on a network, trying to get in. The user is trusted and so is the device in their hand. Defences point outward. Here they point inward, and the inversion changes the meaning of nearly every platform default.
A notification is a disclosure. So is an entry in recent applications, a helpful confirmation email, a badge, an autocomplete suggestion, a backup that syncs somewhere shared, and a search on the device returning a result. Every convenience an operating system offers to remind somebody what they were doing is, in this context, a way for another person to find out what they were doing.
Discovery is itself the harm, and it arrives before any data does. Somebody found with this application on their phone is in more danger than they were before they installed it.
That single fact produced most of the work: not adding protection, but removing traces the platform creates by default.
The five decisions that mattered
If you read nothing else on this page, read this.
What the phone leaves behind matters more than what crosses the network.
Identity is biometric and bound to one device, so there is no address, no password and no recovery route for anybody to use.
No signal, no battery, application closed, and possibly being taken out of somebody's hands.
Every safety feature has an off switch, and the off switch is what an adversary reaches for.
Which makes it evidence rather than a file, and the difference is decided at the moment of capture.
The defences point inward
Standard mobile security practice assumes a compromised network and a trusted device. Encrypt the connection, validate the token, protect the endpoint. All correct, all necessary, and none of it addresses somebody picking up the phone.
The realistic scenario is worse than device access. In a controlling relationship the other person frequently knows the passcode, may have set it up, may check the phone regularly, and asking to see it is not really a question. Any protection that rests on the device being private has already failed.
There is a second constraint. The application has to be usable. A tool so hidden that its owner cannot reach it quickly, under stress, is not protecting anybody either, and there is a real design tension between concealment and speed.
What we did
Traces are treated as the primary surface. What appears in notifications, in system-level lists, in search results and in shared backups is a design decision on every feature. The question asked of each one is what it would tell a person who was not supposed to see it.
Account access is bound to a single device. An account cannot be signed into elsewhere, which closes the path where somebody obtains credentials and looks at the account from their own phone.
Reaching anything sensitive requires the person, not the passcode. A biometric bound to the account gates the paths that matter, because in this situation a passcode is frequently shared knowledge and a face is not.
The defaults are set for the least safe user. Not the average one. Anything that has to be turned on to be safe will be off for the person who most needed it.
Discovery is harder in the way that matters, which is at a glance, by somebody who was not looking for it and now is.
Credentials alone are not enough. Knowing the password does not produce access, which removes the most common route in this threat model.
The safest configuration is the one that arrives. Users under duress do not audit settings, and a safety tool that depends on them doing so protects the wrong people.
The trade is stated rather than hidden. Binding to one device makes recovery harder, and that is a real cost accepted deliberately rather than an oversight.
An account with no credential to steal
Every signup form in ordinary software creates something that can be found, guessed, demanded, or read over a shoulder.
An email address receives mail, and mail is read. A password can be shared, and in a controlling relationship it frequently already is. A confirmation message arrives on a device somebody else picks up. A recovery route exists precisely so that a person who has lost access can get back in, which means it exists for anybody who can convince a system they are that person.
The registration flow is not a preliminary to the security problem here. It is part of it.
What we did
Identity is established biometrically on first use. There is no form to complete, no password to set, and no address to confirm. The account exists, it belongs to one person on one device, and there is no credential in the world that opens it.
Something a person is, rather than something they know. A passcode can be demanded, and asking is not really a question when the person asking lives with you. A biometric cannot be handed over under pressure in the same way.
The account is bound to that device. It cannot be signed into elsewhere, which closes the route where somebody obtains access and looks at the account from their own phone.
The cost, which was accepted deliberately
A lost or destroyed phone means a lost account, because there is nothing to recover it with. That is a genuine cost and it was chosen rather than overlooked. Every recovery mechanism that would fix it is also a door for somebody else, and in this threat model an inconvenient outcome for a person who broke their phone is better than a catastrophic one for a person whose phone was taken.
There is nothing to find. No address in a mailbox, no entry in a password manager, no confirmation in a message history.
Credentials cannot be demanded because there are none, which removes the most direct route in this threat model.
Onboarding got shorter, not longer. The safest design was also the one with the least friction, which is unusual and worth noticing.
The trade is stated rather than buried, because a user should know that losing the phone means starting again.
The alarm fires in the worst conditions
There is often no network. Basements, stairwells, rural roads, dense buildings, and phones with no data left. An alarm that needs a connection to start is an alarm that does not start.
The application is not open. Nobody in danger unlocks a phone, finds an application, and taps through to a screen. Whatever raises the alarm has to work without any of that.
The operating system is trying to save battery. Modern phones aggressively suspend background work, which is correct behaviour and directly opposed to a live alarm.
And the phone may be taken. Once an alarm has started it cannot depend on the device remaining in the right hands or on anything further being done with it.
What we did
Raising an alarm is a local decision. The device commits to it and records it for itself. Reaching the outside world is the next step rather than a precondition, so nothing waits for a connection that may never come.
It keeps trying without help. Everything captured while offline is held and delivered when a connection returns, carrying the time each thing actually happened rather than the time it arrived.
Delivery is safe to repeat. A device regaining signal mid-delivery will retry, so every event carries its own identity and a repeat updates one incident rather than opening a second beside it.
Reliability was tested as the product, not as a quality gate. Online, offline, and the transition between them, on both platforms, repeatedly, because the transition is where this class of system actually fails.
An alarm raised with no signal is still an alarm. The commitment is made locally and delivery catches up.
Nothing depends on the person doing anything else. Once it starts, it continues without further action from somebody whose attention is entirely elsewhere.
One incident stays one incident, however many times a struggling connection delivers it.
Nine times out of ten is not a passing grade. In most categories that is a good application. Here it is a promise that will be broken to somebody, on the worst night of their life.
Cancelling is the attack surface
Every safety feature has an off switch, and the off switch is the one an adversary reaches for. A cancel action anybody can perform means the alarm protects nobody from the person most likely to be holding the device at the moment it matters. Requiring a passcode does not fix it, because in this situation the other person often knows the passcode.
There is an opposing pressure that is just as real. Without any way to stop an alarm, every accidental trigger becomes a response somebody has to explain, and a person who has once summoned help by mistake becomes reluctant to use the feature again. Willingness to press the thing is the resource in shortest supply, and a design that erodes it has failed in a way that never appears in a bug report.
What we did
Cancellation is tied to the person rather than to the device. It requires the biometric bound to the account, which is something a person is rather than something they know and can be made to say.
One device per account closes the second route. An alarm cannot be reached and stopped from another phone somebody else has signed into.
A short delay before anything leaves protects the user's confidence. Long enough that a mistake can be undone. Short enough that it is not long enough for somebody else to undo it for them.
The length of that delay is not ours to decide. It belongs with the people who work with survivors. It is configuration, and the configuration is theirs.
Stopping an alarm requires the person it belongs to, which is the only version of that control that holds up in this threat model.
The user keeps the ability to correct a mistake, which is what keeps them willing to use it at all.
The hardest judgement sits with the people qualified to make it. Software cannot decide how long is long enough here.
The trade-off is visible rather than buried. Two opposing pressures, held in one design, with the balance point adjustable rather than compiled in.
What is captured may be evidence
Material captured during an incident is not a file. It is potentially the account of what happened, produced by somebody with an interest in the outcome, and it may be looked at by a court. It has to be attributable to a time, a device and an incident, and resistant to alteration after the fact.
On the other side of the platform, a responder is not a notification. Sending one consumes finite public resource, and a service producing unreliable alerts is a service responders learn to weight accordingly.
What we did
Capture records its own context. When, on what device, against which incident, written at the time rather than reconstructed from a filename.
Material is the user's. It is theirs, reaching it is gated on them, and every access is recorded.
Responders see one case. Access is scoped to the incident assigned to that responder, for as long as it is theirs. Not a directory, because a list of everybody using a service like this is precisely what it must never become.
A named contact is not a responder. Somebody the user chose receives less, for a shorter period, through access that expires and can be withdrawn.
Every access on both sides is recorded with who, when, and against which incident.
Material has evidential value rather than only emotional value, which is the difference between something that helps in a courtroom and something that does not.
The platform holds a list of people at risk, and can say who looked at it. It is a condition of being trusted with any of it.
Responder credibility is protected, which is what keeps a real response attached to a real alarm for the next person.
The user retains control of their own material, including who else can see it and for how long.
What the platform knows, and about whom
A responder arriving at an incident needs context, and assembling that context creates the heaviest personal record any platform we have built holds.
Who is in the household, including children and their ages, so somebody arriving knows how many people are behind the door.
Health information, including mental health, because it changes how a person should be approached and treated on arrival.
Previous incidents, protective orders and ongoing proceedings, which tell a responder what has already been tried.
Who the risk is from, what the relationship is, and what is known to escalate them.
The part that has no comfortable answer
The record describes two people, and only one of them is a user. Information about the person somebody fears is necessary for a responder and is, in data protection terms, personal data about a third party who has not consented, will not be told, and has no route to see or correct it. That is lawful in the right circumstances, under the provisions that exist for protecting people from harm, and it is never comfortable. It deserves to be stated rather than quietly designed around.
So the record is treated as a liability that happens to be useful
Every field is optional. A person decides what to tell the platform, and the application works with whatever they chose to give.
It is released at an incident rather than held open. A responder sees the profile attached to the case assigned to them, while it is theirs, rather than browsing a directory.
Every read is recorded. Who opened a profile, when, and against which case.
Provenance matters. Where a piece of information came from is part of the record, because a responder acting on something needs to know whether the person told the platform or somebody else did.
A responder arrives informed rather than blind. The profile cannot be browsed. A person is not excluded by an incomplete profile. And the third-party question is visible, which is what makes it possible to handle properly.
The responder side
An alarm that nobody acts on is not a safety feature. The other half of this build is the platform the people responding actually use.
One active alarm at a time. The interface is built around the incident happening now rather than a queue of everything open. A dashboard that presents a live emergency alongside twelve historical cases has buried the thing it exists to surface.
A case has a lifecycle, and it closes. Assigned, in progress, resolved, with notes recorded as they are taken rather than written up afterwards from memory.
Officers are invited, not self-registered. Access to a platform holding this material is granted by an administrator to a named person through their organisation's own authentication.
Assignment is the access grant. A responder sees the case assigned to them, including live material and the profile behind it, for as long as it is theirs. Not the service's user base, and not other people's incidents.
Notes are part of the record. Follow-up actions, referrals and observations are attached to the case, which matters because the next person to deal with this household may not be the same officer.
Response is coordinated rather than improvised, the live incident is the thing on screen, and the question of who saw what has an answer. A platform that dispatches people to emergencies and cannot say who was assigned or what they did is not a safety platform, it is a notification service with a serious job.
The assistant, and the boundary around it
The failure is not a wrong answer. It is a confident one. A model given a description of a frightening situation will produce fluent, specific, plausible advice, and a person in danger will act on it because they have nobody else to ask at two in the morning.
So its scope is defined and narrow. It helps somebody understand and use the application, and it points toward the organisations whose job this is. It does not assess a situation, and it does not tell somebody what to do about the person they live with.
The boundary is held centrally rather than per feature, so tightening it tightens everything at once and improving it does not require a release.
And it does not belong to us. What the assistant may and may not address is a question for the people qualified to answer it, and the platform's job was to make their answer something the software enforces rather than something a reviewer has to catch afterwards.
Two harder problems sitting behind it
Assessing risk is not the same as answering a question. A structured set of questions producing a tailored plan is a risk assessment, and risk assessment in this field is a professional discipline with established instruments. Software can carry an assessment designed by people who do that work. It should not invent one.
And a plan is an artefact. Anything the application produces that a person can keep is a document that can be found, and in this context a document describing somebody's plan to leave is among the most dangerous things they could be holding. So what is produced, where it lives, and whether it survives outside the application are safety decisions rather than convenience ones.
A helpful assistant exists in a context where an unbounded one would be actively dangerous. The people qualified to set the limit can change it without an engineering cycle. And the output of a safety conversation does not quietly become the evidence that the conversation happened.
Which criteria this platform is judged on
Two of the five trust services criteria carry the weight here, and both mean something unusual in this context.
Confidentiality, on this platform, is confidentiality from a person holding the device. Here the party who must not learn something is the one with physical access, ordinary credentials, and a relationship with the user. Single-device binding, biometric gating, and treating platform traces as the primary surface are all answers to that rather than to a network question.
Availability is the second, and it is not a percentage. An alarm that does not fire has not degraded, it has failed completely, at the moment of greatest need. That is why the alarm commits locally, why delivery retries without help, and why offline behaviour was tested as the product rather than as a quality gate.
Privacy is the third and it is unusual here. The platform holds personal data about somebody who is not a user, has not consented, and will not be informed. That is provided for in law where protecting people from harm is the purpose, and it still means the criterion has to be engaged with deliberately rather than assumed satisfied.
Processing integrity sits underneath the evidence handling and the alarm path. An incident that happened must be recorded exactly once, in the state it reached, with what was captured attributable to it.
The control set was designed against the criteria rather than mapped to them afterwards. That is a statement about how the platform was built, not a claim to hold an attestation.
The constraints we designed around
Two operating systems disagree about what an application may do
The challenge. Background execution, always-available entry points, and capture while the screen is off are governed differently on each platform, and the rules change between versions. A safety application depends on exactly the capabilities each platform most restricts.
What we did. Built to what each platform genuinely supports rather than to a shared abstraction that would be weakest on both, and treated capability differences as product decisions rather than bugs.
The application behaves correctly on each platform instead of equally poorly on both. And the differences are known rather than discovered by a user who needed the feature.
Store review does not know what it is looking at
The challenge. An application whose design intent is to be inconspicuous is examined by a reviewer who cannot be told the whole reason.
What we did. Treated review as a design constraint from the start rather than a hurdle at the end, and designed so that everything necessary is explicable.
Distribution is a solved problem rather than a recurring risk, which matters because an update that cannot ship is a safety fix that has not reached anybody.
Testing this is not like testing other software
The challenge. The scenarios that matter cannot be reproduced in an office. No signal, a dying battery, an interrupted action, a device taken mid-alarm.
What we did. Made the difficult conditions the standard test path rather than an exception suite, and exercised the transitions repeatedly on both platforms.
The conditions that matter most are the conditions most often tested, which is the reverse of the usual arrangement and the only one appropriate here.
The people who understand the problem are not engineers
The challenge. Almost every consequential decision on this build is a question about how people behave in frightening situations. Engineering judgement is the wrong instrument.
What we did. Made those decisions configuration rather than code, so they belong to the people qualified to make them and can change without a release.
Expertise reaches production without a developer in the middle, and a decision that turns out to be wrong is corrected in an afternoon rather than a sprint.
The impact, depending on your job
If you run the business
Trust is the entire product. Nobody installs an application like this on the recommendation of a marketing page. It arrives through organisations that will not recommend something they cannot stand behind, and every decision on this page is what makes that recommendation possible.
Restraint is a feature. The decision not to publicise, not to name, and not to describe is itself part of the service.
Responder credibility compounds. A service that produces reliable alerts keeps a real response attached to a real alarm. One that does not degrades the outcome for every later user, permanently.
If you run engineering
The inverted threat model is the part worth your attention, because it is genuinely rare and it changes what good looks like. Defending against the holder of the device makes most standard mobile practice necessary but insufficient, and the work moves to what the platform leaves behind.
Then reliability. Local commitment, delivery that retries without help, identity on every event so repeats converge, and offline treated as the normal case rather than a degraded one.
If you run a delivery team
Most of what is on this page came from deciding where judgement lives. Timings, scopes and boundaries are configuration owned by people who are not engineers, because the questions are not engineering questions.
The testing inversion is the transferable idea: the difficult conditions are the standard path rather than an exception suite. In most products that is over-engineering. Here it is the only arrangement that reflects when the software is used.
If you own the numbers
Reliability is the cost centre and the product at once. The work is concentrated where nothing is visible, which makes it hard to justify by feature count and impossible to skip.
Configuration over code lowers the cost of being wrong, on exactly the decisions most likely to need revisiting.
Distribution risk was designed out early, and an update that cannot ship is a safety fix nobody receives.
Talk to the client, not just to us
Everything on this page is our account of our own work. For this project in particular: if you are seriously evaluating us for work in this category, we will find the appropriate introduction.
Technologies we built with
We name the layers rather than the suppliers, and we do not describe the product. On this project that is not a stylistic choice.
More case studies
View all case studiesBuilding something where the wrong person finding out is the worst outcome?
Tell us what you're building, and we'll tell you honestly how we'd approach it.