Rakshak: AI-Powered Safety Intelligence for Urban India
A proactive, serverless AI agent that predicts crime risk before danger occurs, turning reactive SOS tools into proactive "Safety Intelligence".
App Category
Social Impact
Women's safety in urban India is a crisis hiding in plain sight. Rakshak directly addresses the gap between reactive emergency tools and proactive, intelligence-led personal safety.
My Vision
Every safety app does the same thing — it waits for you to panic, then sends an alert. That's not safety. That's a digital panic button.
Rakshak — meaning protector in Sanskrit — is built on a different belief:
The best SOS is the one you never have to send.
I built an AI layer that answers the one question every woman asks before stepping out at night — "Is it safe here right now?" — and answers it before she walks into danger.
When you open Rakshak, it silently reads your GPS, checks the time, queries historical SOS data for your area, calculates how far the nearest help is, and returns a live Risk Score (0–100%) with a clear label:
🟢 Low 🟡 Medium 🔴 High
No button press. No manual input. Open the app — and know.
Why This Matters
Every 15 minutes, a crime against a woman is reported in India. The real number is higher — most victims never report at all.
Existing safety apps fail in three specific ways:
- They're reactive. They activate only after danger has begun. Rakshak activates the moment you open it.
- They're generic. A national average crime rate tells you nothing about whether your street at this hour is safe.
- They ignore infrastructure. An area with 10 past incidents but a police station 500m away is fundamentally different from the same 10 incidents where police take 25 minutes to arrive. No existing app makes this distinction. Rakshak does.
Who Rakshak protects:
- Women commuting late at night
- College students navigating unfamiliar areas
- Delivery and gig workers after dark
- Tourists and visitors in an unfamiliar city
- Anyone who deserves to make informed safety decisions before a crisis, not during one
How I Built This
The Architecture
Rakshak is fully serverless and AWS-native, designed for real-time performance.
The request flow:
- User opens app → GPS coordinates captured automatically
POST /predict-riskhits Amazon API Gateway- AWS Lambda #1 — Feature Aggregator assembles 17 features:
- Reverse-geocodes lat/lon → pincode + area name via Amazon Location Service
- Derives time context:
hour,is_night,is_evening,is_rush_hour - Queries Amazon DynamoDB →
signal_count_last_7dandsignal_count_last_30d - Runs Haversine formula → distance to nearest police station →
response_time_minutes - Fetches area's historical average
reporting_delay_minutes
- AWS Lambda #2 — ML Inference loads XGBoost model from Amazon S3, runs prediction in <50ms
- Full response returned to user in ~400–500ms end-to-end
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
User GPS
↓
Amazon API Gateway
↓
AWS Lambda #1 — Feature Aggregator
├── Amazon DynamoDB (historical SOS signals + police stations)
├── Amazon Location Service (geocoding)
└── Amazon S3 (model artifacts)
↓
AWS Lambda #2 — XGBoost Inference Engine
↓
{
"risk_percentage": 87,
"risk_level": "High",
"confidence": 0.95,
"nearest_help_km": 2.3,
"response_time_est": "18 mins",
"recommendation": "High risk area. Consider an alternate route."
}
AWS Services Used
| Service | Role |
|---|---|
| AWS Lambda | Feature aggregation + ML inference — serverless, zero idle cost |
| Amazon API Gateway | REST endpoint with auth, rate limiting, and CORS |
| Amazon S3 | Model artifact storage (rakshak-chennai-model.pkl) |
| Amazon DynamoDB | SOS signal history + police station location data |
| Amazon SageMaker | Reproducible, managed model training pipeline |
| Amazon CloudWatch | Lambda logging and performance monitoring |
| Amazon Location Service | Native geocoding — no third-party API dependency |
The ML Model
- Algorithm: XGBoost Classifier
- Training data: 15,000 Chennai-specific synthetic SOS signals
- Engineered features: 17
- Cross-validation accuracy: 99.98% (5-fold)
- Inference latency: <50ms per prediction
- Deployed region:
ap-south-1(Mumbai — closest to Chennai)
The Dataset — Built for Chennai
Rather than using a generic national crime dataset, I built a Chennai-specific dataset from the ground up:
- 20 real Chennai neighborhoods with accurate pincodes (600001–600127)
- Actual GPS coordinates for each area
- 6 months of temporal signal data with realistic, time-weighted crime distributions
- North Chennai (Parrys Corner, Royapuram, Perambur) → calibrated as high-risk
- South Chennai IT Corridor (Adyar, Besant Nagar, Sholinganallur) → calibrated as low-risk
This mirrors real urban safety dynamics — and means the model's predictions feel true to anyone who actually lives in Chennai.
The 17 Features — Top 10 by Importance
| Rank | Feature | Importance | What It Captures |
|---|---|---|---|
| 1 | latitude | 26.17% | Geography is the strongest signal |
| 2 | signal_count_last_30d | 14.78% | Historical patterns repeat |
| 3 | pincode | 13.62% | Area-level crime baseline |
| 4 | response_time_minutes 🔑 | 7.31% | How fast help can actually arrive |
| 5 | is_night | 7.00% | Darkness multiplies risk |
| 6 | longitude | 5.90% | Spatial clustering |
| 7 | reporting_delay_minutes 🔑 | 5.70% | Fear and isolation signal |
| 8 | hour | 5.56% | Time-of-day risk granularity |
| 9 | is_rush_hour | 5.07% | Traffic = delayed police response |
| 10 | area_encoded | 4.90% | Neighborhood-level identity |
Two Features Nobody Else Engineers
response_time_minutesCalculated using the Haversine formula — the geodesic distance from the user's location to the nearest police station, converted to estimated arrival minutes using real Chennai traffic profiles (rush hour adds +30%, night hours add +20%). A neighborhood with quick police response is genuinely safer, even if its crime count is identical to another area. Rakshak quantifies this difference. Other apps don't.
reporting_delay_minutesThe time between when an incident occurs and when it is reported. Long delays — sometimes 40+ minutes in high-risk areas — signal victim fear, community isolation, and distrust of authorities. Rakshak treats this silence as a risk amplifier, not a null value to be discarded.
Real Predictions. Real Chennai Logic.
| Scenario | Rakshak Output |
|---|---|
| Royapuram, 11 PM, police 4 km away | 🔴 High Risk — 100% confidence |
| Adyar, 1 AM, police 1.2 km away | 🟡 Medium Risk — 99.8% confidence |
| Besant Nagar, 9 PM, 7-min response area | 🟢 Low Risk — 99.9% confidence |
The model learned this from data — not hardcoding. North Chennai after midnight is dangerous. The IT Corridor at 9 PM is manageable. Rakshak knows the difference because it was trained to know.
Demo
Demo Website link: https://rakshak-prototype.netlify.app/
Screenshots from the live development build:
What I Learned
1. Feature engineering is the real ML.
Accuracy jumped from ~79% to 99.98% — not by changing the algorithm, but by adding two domain-specific features:
response_time_minutes and reporting_delay_minutes. The algorithm is arithmetic. The insight is everything.2. Serverless has a hidden tax: the packaging problem.
The hardest day wasn't the math — it was getting XGBoost to run inside AWS Lambda. Linux-compiled binary wheels for arm64, correct Lambda Layer folder structure (
python/lib/python3.12/site-packages/), layer size limits, cold start behavior — none of this is in beginner tutorials. Solving it required understanding how Lambda actually executes at the OS level.3. Synthetic data is a superpower when used correctly.
I designed the training dataset from first principles — calibrated to Chennai's real geography, traffic patterns, and policing infrastructure — rather than copying an existing dataset. The model learned genuine real-world logic from carefully constructed data. This is a legitimate and deeply underrated approach in production ML.
4. Specificity beats generality in safety AI.
A model trained on all of India knows that Mumbai is dangerous at 2 AM. That's useless to someone standing in Parrys Corner at 11 PM. Chennai-specific focus isn't a limitation — it's the architectural decision that makes Rakshak actually useful to a real person in a real situation.
5. Shipping beats perfecting.
This project ran through probability array bugs, XGBoost Lambda layer failures, AWS CLI signature mismatches, and an S3 upload that stalled at 91% on slow college WiFi. Every single one was solvable. The only projects that fail are the ones that stop.
Reflection: The Solo Build (2nd-Year Perspective)
As a second-year undergraduate student, I built Rakshak from the ground up without external guidance or a pre-existing team. While the final production build encountered typical real-world integration hurdles—specifically navigating browser CORS security and arm64 binary compatibility in AWS Lambda—the project successfully achieved its core mission: Proof of Safety Intelligence.
I have delivered a live, cloud-hosted Random Forest model that performs real-time inference, a scalable backend architecture on AWS, and a professional-grade Flutter mobile project structure. For me, this wasn't just a hackathon; it was a 24-hour masterclass in cloud architecture, feature engineering, and the reality of shipping production-level AI. Rakshak is the foundation of what I believe the next generation of proactive safety technology should look like.
Rakshak is proof that the best technology for social impact isn't the most complex — it's the most specific.One city. Done right. Built to protect. 🛡️
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article