Forem: Ajit Sharma

VotePath:-an AI-powered election guide.

Ajit Sharma — Sun, 03 May 2026 03:54:09 +0000

VotePath -- an AI-powered multilingual voting guide for first-time voters.

The Problem: Why Don't People Vote?
Millions of eligible voters - especially first-timers, rural citizens, and the elderly - often skip elections simply because the process feels overwhelming. From figuring out eligibility to finding the right polling booth, the friction is real.
During the PromptWars: Virtual Hackathon, I wanted to tackle this exact challenge under the "Election Process Education" vertical. The goal was simple: eliminate confusion and make democratic participation accessible to everyone.
That's how VotePath was born.

What is VotePath?
VotePath is a personalized, AI-powered journey guide designed to hold a voter's hand from the "Not Yet Registered" phase all the way to "After Voting." Instead of dumping a massive PDF of rules on the user, it breaks the electoral process down into an interactive, step-by-step roadmap.
✨ Core Features
🧭 The 5-Stage Voting Journey: An interactive tracker that guides users through specific actionable steps: Not Yet Registered → Registered Voter → Election Announced → Voting Day → After Voting.

🤖 Gemini-Powered AI Assistant: A conversational AI built with the Google Gemini API that answers specific election queries in real-time.
🎙️ Voice Input Accessibility: Integrated the Web Speech API so users can ask questions hands-free.
🌐 Multilingual on the Fly: Seamlessly translates complex election jargon into English, Hindi, Marathi, Tamil, and Bengali using Gemini's translation capabilities.
📶 Offline PWA Support: An integrated Service Worker caches core static assets and the manifesto, ensuring the guide works even in low-connectivity areas.

🛠️ The Tech Stack
To build this rapidly and robustly, I leaned on a modern stack:
Frontend: Next.js 14 (App Router), TypeScript, Tailwind CSS, Framer Motion for smooth UI transitions.
AI & Logic: Google Gemini API (generative-ai SDK) for the brains of the chat and translation.
Analytics: Firebase Firestore to track user journey drop-offs and engagement.
Deployment: Google Cloud Run,Firebase.

Building the UI components and wiring up the Gemini SDK went smoothly using an intent-driven development approach. The real boss fight started during deployment. Next.js is notoriously strict with build errors, and a missing react-confetti package initially crashed my pipeline.
Then came the Docker mismatch. Trying to force heavy local node_modules into a tiny Alpine Linux container led to massive binary conflicts. As the midnight deadline loomed, I ended up ditching the standard Dockerfile approach entirely. Instead, I injected my environment variables directly into Google Cloud Shell and utilized Google Cloud Buildpacks for a native, clean Next.js compilation.
Seeing that Service URL finally pop out of the terminal just as the sun was coming up was one of the most satisfying moments of my developer journey.

The Road Ahead
VotePath was built in a sprint, but the core architecture is highly scalable. The next steps would involve integrating live localized polling data and expanding the accessibility features for visually impaired voters.
Democracy works best when everyone understands how to participate. Technology should be the bridge, not the barrier.

Check it out:
🌐 Live Demo: https://votepath-744150666678.us-central1.run.app/
➡️Preview: https://www.loom.com/share/053b359dac554c3aace6e2cdef7da124
💻 GitHub Repo: https://github.com/ajx1tech/votepath

From Localhost to Cloud: Architecting EquiDex, an AI Bias Detection Platform

Ajit Sharma — Tue, 28 Apr 2026 15:45:53 +0000

Building EquiDex ~ an AI-powered platform designed to audit and detect bias in hiring algorithms was an ambitious undertaking. The goal was to process massive datasets, run them through Google’s Gemini models, and generate legally formatted compliance reports in real-time.

While the core logic was sound on local machine, deploying a full-stack, AI-integrated application to the cloud introduced an entirely new class of engineering challenges.

EquiDex in action 👇

https://youtu.be/hNCHpyAO-ZQ?si=miFw9zgBBuuvYWgu

Here is a deep dive into the (a.)architecture, the (b.)roadblocks, and the ultimate (c.)deployment playbook I developed while bringing EquiDex to life.

(A) The Architecture and Arsenal (Tools & Technologies):-

To handle heavy data processing while ensuring a seamless user experience, I decoupled the frontend and backend, selecting specialized tools for each layer of the stack.

FastAPI (Backend Framework): Chosen for its speed and native asynchronous support. Processing 10,000-row datasets and waiting for AI API responses requires non-blocking architecture, and FastAPI handled this flawlessly.

Google Cloud Run (Serverless Compute): I containerized the backend using Docker to ensure environment consistency. Cloud Run was selected because it scales to zero (cost-effective) and spins up instantly when a request hits, making it perfect for a stateless API.

Firebase Hosting (Frontend Delivery): The UI needed to be fast and globally cached. Firebase Hosting provided a blazing-fast CDN for the static assets and configuration files, securely calling the Cloud Run backend.

SQLite (Database): Used as an ephemeral, lightweight data store. It allowed the system to rapidly cache candidate audits in memory (/tmp/ directory) for immediate AI processing without the latency of an external relational database.

Google Gemini API (2.5 Flash & Pro): The brain of the operation. I used Gemini to ingest the statistical outputs from the database and interpret hidden discrimination patterns, utilizing its massive context window and high token limits.

Faker & Pandas (Data Synthesis): To prove the platform could handle enterprise scale, I wrote a Python script utilizing Faker to dynamically generate 10,000 heavily biased candidate profiles, pushing the AI analysis to its limits.

(B) Into the Trenches (Challenges & Triumphs):-
The transition from local development to a serverless container environment is rarely smooth. Here are the critical bottlenecks I encountered and how I tried resolving them.

The Dependency Blindspot and Docker Contexts:- The Problem: The initial cloud deployments repeatedly crashed with ModuleNotFoundError for packages like python-dotenv and google-generativeai.

The Solution: The issue wasn’t the code; it was the deployment context. Executing the deploy command from within the backend/ directory caused the Google Cloud build system to upload the scripts but ignore the root requirements.txt and Dockerfile. Moving the deployment execution to the project root ensured the entire monolithic context was zipped and built correctly.

The .gitignore Trap & Relative Pathing

The Problem: The container booted successfully but instantly threw a FileNotFoundError when trying to read fairprobe.config.yaml.

The Solution: Google Cloud’s CLI natively respects .gitignore rules. Since .yaml files were ignored to protect secrets, they were silently stripped from the deployment package. I temporarily bypassed this, but a deeper issue remained: relative pathing (open(“fairprobe.config.yaml”)) breaks inside Docker containers. I rewrote the file-handling logic using os.path.abspath(file) to dynamically generate bulletproof absolute paths, regardless of the host environment.

Invisible Characters and Strict Cloud Environments

The Problem: The SQLite database initialization crashed the container with a bizarre near “ “: syntax error despite the raw SQL strings looking flawless in the editor.

The Solution: The Linux-based SQLite engine in the Docker image was strictly rejecting invisible, non-breaking space characters (\xa0) that Windows environments often ignore. I completely sanitized the sqlite.py adapter, reformatted the SQL schema, and implemented strict parameterized queries to prevent both syntax breaks and SQL injection vulnerabilities.

Serverless Amnesia and Read-Only Filesystems

The Problem: The Settings page threw 500 errors when attempting to save configurations, and the AI reports frequently failed to locate the audit data.

The Solution: Cloud Run containers use a strict read-only filesystem (except for the ephemeral /tmp/ directory, which is wiped the moment the container sleeps). I re-architected the app flow: the frontend config was updated to maintain state in memory rather than forcing disk writes, and I optimized the user flow so data ingestion and AI reporting occurred in one continuous, “warm” container session.

(C.) The Deployment Playbook (Key Takeaways):-
Going through this crucible refined my approach to cloud engineering. For developers preparing to deploy their first full-stack application, here are the absolute best practices:

1.Deployments are About Environment Matching: Code that works locally only works because your laptop has specific global variables, relative paths, and installed modules. Dockerizing forces you to explicitly define every single requirement. Never assume the cloud knows what your local machine knows.

Logs are the Ultimate Ground Truth: A generic “503 Service Unavailable” or frontend “Failed to Fetch” tells you nothing. You must read the raw server tracebacks. Finding the exact failing line of code is 90% of the battle.
Design for Ephemerality (Statelessness): When building for serverless platforms like AWS Lambda or Google Cloud Run, assume the server will be destroyed and rebuilt every five minutes. Never rely on the local hard drive to store permanent data, configurations, or sessions.
Manage Secrets at the Container Level: Never hardcode API keys or database URLs in your configuration files. Always use environment variables and inject them securely via CLI or secret managers during the deployment phase.
Test Scale Locally First: AI APIs have strict governors. Before throwing 10,000 synthesized records at a cloud API, test the data pipeline with 10 records. Respect the TPM (Tokens Per Minute) limits, and build error handling for 429 quota codes into your frontend.

Overall learning outcome — —

Deploying EquiDex was a masterclass in debugging, systems architecture, and cloud constraints. It transformed a conceptual prototype into a robust, scalable tool. As a developer, the greatest lesson wasn’t just learning how to write the code, but learning how to teach the cloud to execute it.

🏟️ NaviSmart: How I Built a Crowd-Aware Stadium Navigation Assistant

Ajit Sharma — Tue, 21 Apr 2026 06:53:42 +0000

NaviSmart in action...
(https://www.loom.com/share/5a2d02541d384313b61bb4ac9219c7c3)

🧭 The Problem No One Talks About
You've been to a large sporting event. You know the drill.
You walk into a stadium holding 50,000 people. The signage is confusing. The crowd is thick. You need to get from the registration desk to Workshop Hall A — but three corridors look identical, every checkpoint has a queue, and your phone's GPS is useless indoors.
You're lost. You're late. You're frustrated.
This isn't a small inconvenience — it's a systemic failure of physical event design. And it's exactly what the PromptWars: Virtual Hackathon challenge asked us to solve:

"Design a solution that improves the physical event experience for attendees at large-scale sporting venues. The system should address challenges such as crowd movement, waiting times, and real-time coordination."

My answer was NaviSmart! a crowd-aware, AI-powered stadium navigation assistant that lives in your browser and speaks plain English.

🔗 Try the live prototype here: https://navismart.vercel.app/

☁️On Google Cloud : https://navismart-1079610432559.us-central1.run.app

💡 The Idea: What if the Venue Could Talk to You?
Most navigation apps are built for roads. Google Maps is phenomenal outside — but inside a stadium, with gate numbers, workshop halls, food courts, and first-aid stations, it falls flat.
What I wanted to build was something fundamentally different:

A conversational interface layered on top of a live interactive map, where attendees type naturally — "Guide me from Registration to Hall A, avoiding the crowd" — and get a real, drawn route with crowd context.

The core insight was combining two things that had never been combined for venues:

Natural language understanding (so anyone can use it, no learning curve)
Live crowd density awareness (so the route isn't just shortest — it's smartest)

That became NaviSmart.

🏗️ Architecture: How It All Fits Together
User types natural language
↓
routeParser.ts (NLP Intent Engine)
↓
Extracts: { from: "Registration Desk", to: "Workshop Hall A" }
↓
Google Maps Directions API (real walking route)
↓
crowdSimulator.ts (wait times + density per location)
↓
formatRouteResponse() → Chat message with steps
↓
StadiumMap draws Polyline route in real time
↓
User sees route on map + step-by-step chat directions
The beauty of this architecture is its modularity. Each piece does one thing:

The parser handles language
The Directions API handles geography
The crowd simulator handles context
The map handles visualization
The chat interface handles communication

No single component is overloaded. Swap any one of them and the rest still works.

🛠️ Tech Stack — Every Choice Explained
⚛️ Next.js 14 (App Router) + TypeScript
Next.js with the App Router gives us server components, optimized image loading, and a clean routing model out of the box. TypeScript ensures every function contract is explicit — critical when you're building fast and can't afford runtime surprises.
🎨 Tailwind CSS
Dark-themed UI, built in minutes. No custom CSS files. Tailwind's utility classes let you design directly in JSX — perfect for a hackathon where design speed matters.
🗺️ @react-google-maps/api
The best React wrapper for Google Maps. It gives us useJsApiLoader, GoogleMap, Marker, and Polyline components as proper React primitives — no DOM manipulation, no lifecycle hacks.
📍 Google Maps JavaScript API + Directions API
The Maps JS API renders the interactive venue map. The Directions API computes real walking routes between GPS coordinates. Together, they give NaviSmart its geographic intelligence.
🧠 Custom NLP Intent Parser (routeParser.ts)
No LLM API calls needed. A smart regex + keyword matching engine that handles every natural language pattern a user might type:

"Guide me from X to Y"
"How do I reach Y from X"
"Navigate from X to Y"
"Get me to Y"

It maps recognized phrases to canonical location names and returns structured { from, to } objects.
🚦 Crowd Simulator (crowdSimulator.ts)
A deterministic crowd density model that assigns each venue location a crowd level (Low/Medium/High), estimated wait time in minutes, and a color-coded emoji indicator. In a production system, this would pull from real IoT sensor data or Google Maps Popular Times.
🐳 Docker + Google Cloud Run / Vercel
The app is containerized using a multi-stage Dockerfile with Next.js standalone output — keeping the final image lean. Deployed live on Vercel for the hackathon demo.
🧪 Jest Unit Tests
Unit tests cover the core logic: intent parsing, crowd level retrieval, and input sanitization. These aren't afterthoughts — they're what separates a prototype from a production-ready system.

🔍 Feature Walkthrough

🗺️ Interactive Venue Map
The top 60% of the screen is a live Google Map centered on the venue, showing 6 key locations as custom markers:
LocationEmojiCrowd LevelRegistration Desk📋🟡 MediumMain Gate🚪🔴 HighFood Court🍔🔴 HighFirst Aid🏥🟢 LowWorkshop Hall A🎓🟢 LowExit🚶🟡 Medium
When a route is computed, a blue Polyline is drawn dynamically on the map tracing the exact walking path.
💬 AI Chat Interface
The bottom 40% is a clean dark-themed chat window. Users type naturally:
You: Guide me from Registration to Hall A
NaviSmart responds:
🤖 NaviSmart:
🗺️ Route: Registration Desk → Workshop Hall A
⏱️ Est. time: 4 mins
🚦 Crowd at Hall A: 🟢 Low (~1 min wait)

📍 Step-by-step:

Head north from Registration toward the central concourse
Turn left at the main corridor junction
Continue past the media zone
Workshop Hall A will be on your right

💡 Tip: Registration Desk is currently Medium — expect a short wait if returning.
The response is informative, actionable, and human. Not robotic output — a genuine assistant voice.

🛡️ Security-First Design A hackathon project that handles user input has real security responsibilities:

XSS Prevention: All user input is sanitized via a regex strip of HTML tags before processing
API Key Safety: The Google Maps API key lives exclusively in .env.local — never committed to git, never hardcoded
.gitignore discipline: node_modules/, .next/, and all .env*.local files are excluded from the repository

♿ Accessibility by Default NaviSmart was built with accessibility as a first-class concern, not a checkbox:

aria-label on every interactive element
aria-live="polite" on the chat message feed (screen reader announcements)
Semantic HTML: , , used throughout
High-contrast dark theme with clear visual hierarchy
Keyboard navigation supported for the chat input

⚡ Building with Google Antigravity: Intent-Driven Development
The most unusual part of this project wasn't the technology — it was how it was built.
PromptWars: Virtual mandates the use of Google Antigravity, an intent-driven development tool. Instead of writing code line by line, you describe what you want in structured natural language prompts, and Antigravity generates the implementation.
Here's what that looked like in practice:
Prompt 1 — "Scaffold a Next.js 14 app with TypeScript, Tailwind, @react-google-maps/api, set up .env.local with placeholder API key, configure .gitignore"
Prompt 2 — "Build a split-screen layout: top 60% is a Google Map with 6 custom markers and a Polyline component, bottom 40% is a dark-themed chat interface with accessible ARIA labels and semantic HTML"
Prompt 3 — "Add Google Directions API integration, crowd simulator with per-location wait times, NLP intent parser with regex matching, and a formatted route response generator"
Prompt 4 — "Add Jest unit tests for the parser and crowd simulator, create a multi-stage Dockerfile with Next.js standalone output, write a comprehensive README"
Four prompts. A fully functional, tested, deployed web application.
This is what the future of software development looks like: you architect, the AI implements. The developer's job shifts from syntax to systems thinking.

🌍 Real-World Applications
NaviSmart isn't just a hackathon demo. With modest extension, it becomes genuinely deployable:
🏟️ Sports Stadiums
Real-time crowd routing for NFL, IPL, or Premier League venues. Integrate with turnstile sensor data for live density maps.
🎪 Music Festivals & Concerts
Guide attendees between stages, merchandise stalls, and medical tents. Reduce crush risk at bottleneck corridors.
✈️ Airports & Transit Hubs
Indoor navigation for terminals, gates, customs, and lounges. Layer on flight delay data for proactive rerouting.
🏫 Universities & Campuses
Wayfinding for new students, exam-day crowd management, and accessibility routing for mobility-impaired users.
🏥 Hospitals
Navigate between departments, reduce wait-room overcrowding, direct visitors without staff interruption.
🛍️ Shopping Malls
Promotional routing ("take the scenic path past our featured stores"), parking guidance, event-day crowd management.

🔮 What's Next for NaviSmart
If I were to take this beyond a hackathon prototype:
v2.0 Features:

🎙️ Voice input via Web Speech API — hands-free navigation
📡 Real IoT crowd data — live sensor integration instead of simulation
🔔 Push notifications — "Your route to Hall A just cleared up!"
🌐 Multi-language support — for international venues and global events
🧭 Indoor positioning — Bluetooth beacon integration for precise indoor GPS
📱 PWA support — installable on mobile, works offline with cached venue maps
🤝 Staff coordination mode — separate interface for event staff to manage crowd flow

! Closing Thoughts
NaviSmart started as a response to a hackathon prompt and became something I genuinely believe in.
The problem it solves = people being lost, stressed, and stuck in crowds at events they paid to enjoy is real. The technology to fix it exists. What was missing was the right interface: conversational, ambient, and crowd-aware.
Building this in under 2 hours with Google Antigravity showed me something important: the bottleneck in software development is increasingly not implementation & it's ideation, architecture, and judgment. Those are irreducibly human.
The tools are getting faster. The ideas still need us.