Back to case studies Business Analysis · Safety Product Case Study

FindFam

A privacy-first family safety platform for consent-based live location sharing, trusted circles, contextual chat, emergency contacts, and real-time SOS alerts—designed to support connection without turning safety into surveillance.

Product DiscoveryPrivacy by DesignReal-Time WorkflowsSOS RulesRequirementsTech Stack

01Business Problem & Objectives

Families and close groups need a fast way to coordinate and ask for help, but many location products can feel like permanent one-way monitoring. Switching between maps, messages, calls, and emergency contacts also slows communication when context matters most.

  • Objective 1: Make location sharing voluntary, visible, and reversible for every circle member.
  • Objective 2: Combine the live map, circle chat, and safety context in one trusted space.
  • Objective 3: Deliver SOS alerts immediately to circle members and nominated emergency contacts.
  • Objective 4: Give moderators operational visibility without allowing normal user accounts to gain admin privileges.

02Current-State vs Target Journey

Current state: A person shares location in one app → explains the situation in another chat → calls contacts individually if risk increases → recipients lack a single, current view of who needs help and where.

Target state: User joins a trusted circle by invite → explicitly enables sharing → circle sees the same live map and contextual chat → user raises SOS from the mobile device → the platform broadcasts the event and sends push alerts → authorised moderators can monitor active SOS events.

Scope rule: Browser sharing works only while the tab is open and clearly states that limitation. Raising an SOS remains mobile-only because the phone is the device expected to be present during an emergency.

03Functional Requirements

  • FR1: Users can create a private circle or join one using a controlled invite code.
  • FR2: Members can start and stop location sharing, and the interface communicates their current sharing state.
  • FR3: Authorised circle members receive live location updates on a shared map.
  • FR4: Circle members can exchange contextual messages through real-time chat.
  • FR5: Mobile users can raise an SOS that records the latest location and notifies the circle and emergency contacts.
  • FR6: Users can manage emergency contacts and follow relationships according to consent rules.
  • FR7: Moderators use a separate credential store and session to review users and monitor live SOS events.

04Non-Functional Requirements

CategoryRequirement
PrivacyLocation is shared only with authorised relationships and stops when the user withdraws consent.
SecurityUser and administrator identities use separate authentication boundaries; role checks are enforced server-side.
PerformanceLive map, chat, and SOS events propagate to connected recipients with minimal real-time delay.
ReliabilityQueued notification jobs retry safely and do not create duplicate SOS records.
TransparencyThe product clearly communicates sharing state, browser limitations, alert recipients, and the limits of the service.
ScalabilityLocation queries use geospatial indexing and realtime fan-out is separated from persistent storage.

05User Story & Acceptance Criteria

As a circle member who feels unsafe, I want to send one SOS with my latest location, so that trusted people are informed immediately without me contacting each person separately.

  • Given an authenticated mobile user in a circle, when they confirm SOS, then one active SOS event is created with time and latest available location.
  • Given an SOS is created, when connected circle members are online, then they receive the event through the real-time channel and see it on the map.
  • Given recipients are offline, when the SOS is raised, then eligible circle members and emergency contacts receive a queued push notification.
  • Given an active SOS, when it is resolved or cancelled, then status changes are timestamped and broadcast to recipients.

06Use Case: Raise an SOS

ActorAuthenticated mobile user
PreconditionThe user belongs to a circle and has accepted the SOS confirmation prompt.
Main flow1. User opens SOS. 2. App obtains the latest permitted location. 3. User confirms. 4. API creates an SOS event. 5. Realtime gateway broadcasts it. 6. Background workers send push alerts. 7. Circle members and moderators see active status.
Alternate flowIf location is unavailable, the SOS is still created with a clear “location unavailable” state instead of silently failing.
PostconditionA traceable SOS record exists and eligible recipients have been notified or queued for notification.

Explore FindFam

Review the product documentation, architecture, source code, and current delivery status.

View repository