Building TrackSafe V1: A Journey into Zero-Friction Emergency Device Recovery

Device theft is a staggering global crisis, costing users billions of dollars annually and introducing immense emotional and financial trauma. In emerging markets across Africa, the problem is compounded: when a phone or laptop disappears on a bus in Lagos, traditional track-and-trace systems immediately fail the moment a thief powers down the device or rips out the SIM card. Relying on slow, bureaucratic law enforcement workflows means that by the time an official report is generated, the device has already been wiped, stripped, or resold.

This reality inspired the creation of TrackSafe is an affordable, robust, and offline-resilient device recovery platform designed to recover stolen electronics in hours, not weeks, by bypassing traditional operational bottlenecks.


The Problem & The Core Value Proposition

Traditional solutions suffer from severe structural limitations: Google and Apple "Find My" ecosystems: Highly dependent on continuous cellular network coverage or active Wi-Fi data paths. Third-party background tracking apps: Infamous for persistent battery drain, complex setup interfaces, and critical data privacy vulnerabilities.

TrackSafe’s Core Value Proposition: Every second wasted empowers the adversary. TrackSafe optimizes this formula by establishing a zero-friction out-of-band recovery loop. When a user triggers an emergency isolation sequence, the system immediately locks the target device, freezes cryptographic identity footprints natively, and routes highly secured recovery endpoints directly to trusted emergency backup contacts via cellular SMS networks ensuring actionable tracking variables remain available even if the primary victim's screen goes dark.

How We Built TrackSafe V1

The design architecture of TrackSafe V1 was forged as an agile collaboration between engineering direction, full-stack implementation handled by our developer MeDo, and precise structural orchestration engineered in tandem with Gemini & Claude.

[User App/Crisis Trigger] 
       │
       ▼ (Secure RPC / SECURITY DEFINER)
[Supabase Production Postgres Engine] ──(Webhook Insert)──► [Edge Functions]
       │                                                         │
       ▼ (Row Level Security Active)                             ▼ (Termii API Gateway)
[Protected theft_reports Table]                            [Out-of-Band Helper SMS]

The underlying technical stack leverages an enterprise-grade backend coupled with an optimized, lightweight frontend engine:

  1. The Infrastructure Layer (Supabase & PostgreSQL): The system operates on a centralized relational instance hosted on our production cluster (https://yqpfamtypoxomyhqnsih.supabase.co). Data isolation and absolute privacy are strictly governed by Row Level Security (RLS) policies.

  2. Serverless Orchestration (Supabase Edge Functions): Specialized typescript hooks process sensitive operations out-of-band, preventing cryptographic keys or API credentials from leaking into client bundles.

  3. Telephony Routing (Termii Gateway): Critical emergency alerts, security authentication keys, and link dispatches are processed and transmitted globally using specialized SMS communications infrastructure.

  4. The Client Interface (React & TypeScript): Tailored mobile-responsive layouts ensure rapid UI performance under real-world cellular bandwidth degradation conditions.

⚡ Technical Breakthroughs & Engineering Iterations

Building an emergency system meant our engineering pipeline faced multiple rigorous quality gates and technical refactors. Throughout development, we tackled three structural bottlenecks:

1. Hardening the Public Recovery API Gateway

Initially, anonymous portal lookups targeted the raw theft_reports table directly. However, opening broad public SELECT access introduced data scraping risks. To eliminate this vulnerability, we decoupled public table reading entirely and routed queries through secure database RPC layers: get_device_preview_by_ticket and get_recovery_data.

By executing these procedures as SECURITY DEFINER, the public portal securely fetches exactly one matching record using a tokenized URL, keeping the base table fully protected.

2. Resolving Data-Type Collisions (UUID vs. TEXT)

During deployment testing, manual entries (15-digit IMEI strings) and query tokens (36-character UUID strings) collided within the Postgres engine, causing silent execution crashes. We resolved this by implementing an adaptive parameter-matching procedure capable of resolving both types natively:

3. Fixing the UX State and OpSec Flashes

Early user flows experienced a minor timing delay that briefly flashed the initial IMEI form before detecting parameters in the link. We addressed this by implementing a non-interactive ticketResolving state on the frontend. This completely suppresses initial form components and smoothly advances authenticated tracking links directly to key verification inputs.

Lessons Learned & Strategic Roadmap

Developing TrackSafe V1 reinforced a vital engineering principle: **in a crisis scenario, user experience and operational security are deeply linked. An application can possess powerful cryptographic architectures, but if the interface leaks state updates prematurely or demands complex authentication credentials during an emergency, the system fails the user.

The Next Steps: Moving from Web to Native (V2)

While our mobile-optimized web platform successfully handles core tracking workflows, web browsers naturally lack direct hardware access. Our strategic roadmap addresses these native boundaries:

Phase Milestone Core Engineering Target
**V1 (Current) Deployed Web Ecosystem

| Secure RPC validation via production Supabase cluster, out-of-band Termii SMS routing.

| | **V2 (Q3 2026) | Native Alpha Launch

| Transitioning background services to iOS CoreLocation and Android WorkManager for continuous geofencing and location sync.

| | **V3 (Q4 2026) | Low-Level Telephony

| Integrating iOS CallKit and Android Telephony Manager to detect abnormalities such as unauthorized SIM card extraction instantly.

We aim to achieve this by coupling cloud infrastructure with underlying operating system security architectures.

Our Mision at TrackSafe is building a resilient, ironclad security safety net for personal device protecting digital identities one secured Trigger at a time.

Built With

  • appmedo
  • deno
  • highly-modular-single-page-application-(spa).-typescript-interfaces-strictly-enforce-our-device-and-report-payload-schemas-across-the-frontend.-*-**tailwind-css:**-utilized-to-craft-a-clean
  • javascript
  • mobile-first-design-language-optimized-for-high-stress-crisis-situations-where-users-need-immediate
  • postgresql
  • react
  • sms
  • sql
  • supabase
  • tailwind
  • termii
Share this project:

Updates

Submission history