The problem shakti360-guardian solves

Personal safety tools often depend on continuous tracking, complicated setup, or vague AI predictions. Shakti360 Guardian provides practical protection while keeping the user in control.

People can use Shakti360 to:

• Start a temporary safety journey with an expected arrival time and battery-aware check-ins.
• Notify selected trusted guardians about journey starts, missed check-ins, SOS events, and safe arrivals.
• Share expiring guardian invitations through SMS, email, clipboard, or the device share menu.
• Find nearby hospitals, clinics, pharmacies, and police using current OpenStreetMap data.
• Check suspicious messages for scam indicators and receive explainable guidance.
• Document incidents and organize evidence without making unsupported legal or safety claims.
• Review privacy settings, emergency readiness, and incident patterns.
• Install the platform as a responsive PWA on desktop, Android, iPhone, or iPad.

Unlike permanent location-sharing products, Shakti360 uses purpose-bound sessions. Sharing is intended to stop when a journey ends, and escalation remains deterministic and human-controlled. The platform never claims to guarantee safety or automatically contact emergency services.

Challenges I ran into

Challenges I ran into

• Python 3.14 dependency incompatibility: pydantic-core attempted a local Rust build and failed during Windows linking. I standardized the backend on Python 3.12 so compatible wheels install reliably.

• Railway monorepo deployment: Railway initially deployed only the Expo frontend, leaving Nginx unable to reach FastAPI. I created a single full-stack Docker image that builds the PWA, runs FastAPI on loopback, and exposes both through Nginx on Railway’s dynamic port.

• API proxy and CORS failures: Production bundles initially attempted to call localhost:8000. I replaced this with a same-origin /api gateway, explicitly rewrote API paths in Nginx, and removed the browser’s dependency on private Railway DNS.

• Authentication behind a proxy: Refresh cookies scoped to /auth were not sent to public /api/auth routes. I corrected cookie paths, retained CSRF protection, and added regression tests.

• Database startup failures: An unresolved Railway DATABASE_URL reference caused FastAPI to crash before health checks. I added URL normalization, PostgreSQL/Psycopg support, validation, clear warnings, and a safe SQLite demo fallback.

• Stale PWA deployments: An incorrect Workbox navigation fallback displayed the offline page even while Railway was healthy. I replaced it with network-first routing and a true offline-only fallback.

• React hydration mismatch: Server-rendered and browser-rendered trees occasionally differed, producing React error #418. I introduced a deterministic hydration boundary before mounting browser-dependent functionality.

• External-provider reliability: Twilio trial restrictions and slow OpenStreetMap requests affected the experience. The app now provides actionable provider errors, copy/share invitation fallbacks, and bounded nearby-resource timeouts.

• Restarted journey state: The browser could restore a journey that the restarted backend no longer recognized. Restored journeys are now verified with the API and stale local state is recovered safely.

The final system passed 66 automated backend tests and 36 live production smoke-test operations across all major API capabilities.

Technologies used

• TypeScript
• React 19
• React Native
• Expo
• Expo Router
• Progressive Web App APIs
• Workbox service workers
• FastAPI
• Python 3.12
• Pydantic
• SQLAlchemy
• PostgreSQL
• SQLite fallback
• Argon2 password hashing
• JWT authentication
• CSRF protection
• Nginx
• Docker
• Railway
• Twilio SMS API
• Resend Email API
• OpenStreetMap and Overpass API
• Pytest
• HTTPX
• GitHub

Platforms

• Web
• Progressive Web App
• Desktop browsers
• Android through installable PWA
• iPhone and iPad through Add to Home Screen
• Expo-based Android and iOS native-release ready
• Railway cloud deployment