Kaali

Kaali started as a competition entry, the AFGJI Inter-School Design Thinking Competition, website design category, submitted at the end of April 2026, and turned into something I care about more than most competition projects usually deserve. The brief, self-assigned, was blunt: build a women's safety app that could plausibly matter, not a demo that looks good in a five-minute pitch and does nothing real underneath. Whether it fully clears that bar yet is a fair question. I'd rather answer it honestly than oversell it.

The core idea is a voice-triggered emergency system. Speak a specific phrase, a mantra, in the app's own language for it, and it triggers an alert, even with the phone locked or sitting in a bag, because the entire premise of a real emergency is that you may not have a free hand or a free moment to unlock a screen and tap through an interface. That constraint shaped almost everything else about the build: if the core safety feature only works when someone has time and privacy to use it properly, it's not actually a safety feature, it's a UI exercise wearing a safety feature's name.

Eight modules, each named and each doing one job

I split the app into eight distinct pieces, each with a Sanskrit name and a specific, narrow responsibility rather than one monolithic "safety app" screen trying to do everything at once. Trishul is the core SOS system: a hold-to-activate orb for the primary alert, plus a fake-call escape feature that simulates an incoming call from a saved contact like "Maa" or "Papa," with a ten-second countdown that auto-dials emergency services if nothing cancels it. Drishti is a dark-themed incident map built on Leaflet, seeded with over thirty incident markers spread across thirteen Indian cities. Devi is an offline chatbot, no API calls, no external dependency, ten hand-built intents matched by keyword, because a safety app that goes silent the moment cell signal drops has failed at the one moment it matters most. Rakshak manages a guardian circle of up to five trusted contacts. Sangha holds community reports and testimonials. Gyaan is a legal-literacy module covering ten real Indian laws, IPC sections on assault and harassment, the POSH Act, domestic violence protections, the IT Act, with a six-question quiz to check whether the information actually landed. Smriti is an evidence vault for audio, journal entries, and photos, exportable as JSON. Darshan is the dashboard tying it together, with a safety score and badges.

Under the hood it's deliberately unfancy: vanilla HTML, CSS, and JavaScript, no framework, built as a real Progressive Web App with a proper service worker so it installs and runs offline. It leans on browser APIs directly: SpeechRecognition for the voice trigger, Geolocation, MediaRecorder for evidence capture, Notification and Vibration for alerts that actually get noticed. Storage is local, localStorage and IndexedDB, but the storage layer is explicitly written to be swapped for Firestore later without a rewrite, which was a conscious hedge: build the offline-first version first, prove the interaction model works, and leave the door open for a real backend once the app justifies one.

Where the demo and the reality actually diverge

I want to be direct about the gap between the competition materials and what's actually built, because it's a real gap and it matters more here than in almost any other project in this list. This is a safety app, and overselling a safety app is a worse category of dishonesty than overselling a dev tool. The competition synopsis frames the incident data and testimonials as real, and they aren't. They're seeded demo content, clearly fictional, built to demonstrate what the feature would look like populated with real reports rather than to represent actual verified incidents. The projected "one million users" framing in the synopsis is competition-pitch language, not a real user base. There are zero users today, because this hasn't launched anywhere. And the guardian alert system, right now, doesn't actually send anything off-device. Everything lives locally, on the one phone that has the app installed. A real alert reaching a real guardian's real phone requires a backend that doesn't exist yet.

None of that means the underlying idea is fake. It means the idea is proven at the interaction-design level, the voice trigger works, the fake-call escape works, the offline chatbot answers correctly, the legal content is real and accurate, and not yet proven at the level that would let a real person depend on it in a real emergency. There's a meaningful difference between "this works as a demo" and "this works when someone's safety actually depends on it," and I'm not going to blur that line just because the demo version is genuinely functional and looks finished.

What actually finishing this would require

A real backend, so guardian alerts leave the device. Real verified incident data instead of seeded placeholders, which means either a data-sharing partnership or a genuine reporting pipeline with the moderation that implies. And an honest look at whether voice-trigger detection is reliable enough, across accents and ambient noise and stress-affected speech, to trust with something this serious. That's not a question I can fully answer from a competition build alone, and I don't think it's responsible to pretend otherwise.

Why offline-first wasn't a technical preference, it was the requirement

Devi being an offline chatbot, keyword-matched intents instead of a real LLM behind an API call, reads, out of context, like a limitation I settled for because building a real AI assistant would have taken longer. That's not why I built it that way. A woman in an actual emergency situation may have no signal, may be somewhere cell coverage is spotty by design of the situation itself, and an app that goes silent the moment connectivity drops has failed at precisely the moment it exists to serve. Ten hand-built intents, matched by keyword, running entirely on-device, will never be as capable as a real language model, but it will never go silent either, and for this specific feature, in this specific app, reliability under bad conditions matters more than sophistication under good ones. That's a real design tradeoff, made deliberately, not a corner cut for lack of time.

What I learned building the legal-literacy module

Gyaan was the module I expected to be the least interesting to build and ended up caring about the most. Summarizing real Indian law, IPC sections, the POSH Act, the domestic violence protections, accurately enough to trust, in language a teenager building this in her or his spare time could actually get right, meant real research, not just paraphrasing a Wikipedia page. I cross-checked every section against actual legal text before it went into the app, because getting a safety app's legal information wrong isn't a bug in the normal sense. It's the kind of mistake that could genuinely mislead someone about what protection they're entitled to at the exact moment they need to know clearly. That module took longer per feature than anything else in the app, and it should have.

Full stack developer. Founder of Yashveer Labs. This one matters more than most of what's on this list, precisely because it isn't finished yet.