Inspiration
TravSec began with a simple concern: travelers and vulnerable people can find themselves in uncomfortable or dangerous situations where they cannot understand the language around them. Existing safety tools often depend on the user already recognizing the threat and acting quickly. We wanted to explore whether an app could provide a discreet, multilingual layer of awareness—without pretending to be an emergency service or making irreversible decisions for the user.
This is an early alpha and proof of feasibility: a reinforcement that this kind of safety-awareness workflow can be built thoughtfully on a phone.
What it does
TravSec is an Android-first, privacy-conscious safety awareness app. With clear user consent, it listens for speech, uses voice activity detection to isolate likely speech segments, transcribes them through multilingual AI services, and classifies potential high-risk situations.
For the MVP, it can surface discreet, generic notifications for categories such as violence, coercion, and pursuit. It is designed as an experimental awareness aid: it does not contact emergency services, does not replace human judgment, and does not save recordings.
We route popular-language transcription through Whisper Large V3 Turbo and use Chirp 3 for lower-resource language coverage such as Hindi and Nepali, where our validation showed stronger results.
How we built it
We built the mobile app with Flutter and Dart, with Android-native Kotlin code for foreground microphone capture and notification behavior.
The app captures audio at 16 kHz, downsamples to 8 kHz for an efficient Silero VAD path, and keeps only a bounded in-memory audio window for analysis. We used spike tests on a real Android device to validate microphone permissions, foreground-service behavior, VAD performance, recording boundaries, multilingual transcription quality, and end-to-end alert delivery.
For AI, TravSec uses OpenRouter transcription models and OpenAI structured outputs for risk classification. We use typed schemas to keep classifier responses predictable and safely constrained.
We initially implemented a containerized FastAPI backend, then decided to move API orchestration to Firebase Cloud Functions. That reduced deployment friction for this alpha and removed an unnecessary container-hosting layer from the mobile testing workflow.
Challenges we ran into
The difficult part was not creating a Flutter screen—it was making the whole operational surface reliable.
We had to account for noisy environments, distinguish human speech from non-speech efficiently, manage Android microphone permissions and foreground-service requirements, preserve app state across lifecycle changes, and avoid retaining sensitive audio or transcripts.
Multilingual quality was another major challenge. Our tests showed that a cost-efficient model could work well for common languages but perform poorly for Hindi and especially Nepali (since both of us, we're Nepali). Comparing several transcription models gave us evidence to use a more capable fallback for lower-resource languages instead of relying on a single model everywhere.
Latency, request costs, duplicate alerts, and notification fatigue also required careful design. The app uses bounded queues, short-lived in-memory data, structured responses, and alert cooldowns to make the experience more practical.
Accomplishments that we're proud of
- Validated the full Android microphone-to-alert flow on a physical phone.
- Built a consent-first, foreground-service-based listening experience.
- Tested audio capture and VAD paths instead of assuming they would work.
- Compared multilingual transcription quality across models using the same recordings.
- Found a practical routing strategy: Whisper Large V3 Turbo for popular languages and Chirp 3 for Hindi, Nepali, and similar lower-resource cases.
- Delivered generic lock-screen-safe alerts and a local, privacy-minimized alert history.
- Kept recordings ephemeral and avoided storing raw audio or full transcripts.
- Turned a complex local Docker prototype into a simpler serverless deployment direction.
What we learned
We learned that spike tests are not overhead—they are architecture tools. Testing real audio, real Android lifecycle behavior, and real multilingual samples early saved us from spending time rewriting assumptions into code.
We also learned that multilingual support is not a checkbox. Model quality varies substantially by language, especially for lower-resource languages. A routing strategy based on evidence is more useful than claiming one model is best for everyone.
Finally, building for safety requires restraint. Clear consent, limited data retention, generic notifications, and honest product language matter as much as model accuracy.
What's next for TravSec
TravSec remains an internal-alpha proof of concept. Next steps include:
- Completing the Firebase Cloud Functions deployment path.
- Adding secure tester access and environment-specific configuration.
- Expanding multilingual validation with more speakers, accents, and noisy settings.
- Exploring optional language-routing approaches beyond the MVP.
- Improving risk explanations while keeping notifications discreet and non-alarming.
- Evaluating edge transcription options for Hindi, Nepali, and other regional languages.
- Investigating future speaker-awareness and scam-pattern support without overclaiming what the system can infer.
- Conducting a controlled pilot focused on India, Hindi, Nepali, and traveler-oriented safety scenarios.
Log in or sign up for Devpost to join the conversation.