Scholarship Navigator

• 

  Home

• 

  Register

• 

  About

Scholarship Navigator

Inspiration

There are 50+ central and state government scholarship schemes in India for SC/ST/OBC/EWS students, minority communities, girls in technical education, students with disabilities, and more — covering everything from Class 9 to PhD. But they live across 20+ disconnected portals (NSP, AICTE, MahaDBT, ePASS, e-Grantz, and a dozen others), each with its own eligibility rules, income ceilings, and document requirements.

The result isn't an eligibility problem — it's a discovery problem. Most students apply to the one or two schemes they happen to hear about from a teacher or a friend, and never find out about the rest. We wanted to build something that flips that: register your details once, and see everything you actually qualify for, in one place, explained in plain language.

What it does

Scholarship Navigator is a single-page web app where a student:

Registers a profile once — education level, category, state, family income, minority/disability status Sees every scheme they qualify for, matched automatically against a database of 49 central and state schemes Understands why they qualify — each match shows plain-language reasons ("you're pursuing an undergraduate degree," "your income is within the limit") instead of just a checkmark, so eligibility isn't a black box Gets a document checklist and next steps for each scheme, so they know what to gather before they start Logs an "applied" receipt and is handed off to the correct official government portal to complete the real submission — the tool never pretends to submit on the student's behalf Can ask a chat assistant questions about their specific matches — but only their matches; the assistant is explicitly restricted from answering with information outside the data it's given

How we built it

A single self-contained HTML/CSS/JS file — no build step, no backend. Eligibility logic is pure client-side matching against a structured scheme database (income ceilings, category/level/state filters, minority/gender/disability flags). Profile and application data persist per-user; the chat assistant calls the Claude API with a system prompt scoped strictly to the student's own matched schemes, so it can't invent facts about scholarships it wasn't given. We deliberately kept the architecture simple — a backend would have added deployment risk and complexity without actually solving the harder problem, which is that scholarship rules aren't available through any clean, unified API in the first place.

Challenges we ran into

There is no single source of truth for scholarship data. Government portals don't expose machine-readable eligibility rules; figures are scattered across PDFs, state portals, and aggregator sites that often disagree with each other. We found cases where even "official" figures were mid-revision — one scheme's income limit had a government panel proposal to raise it that hadn't taken effect yet. Rather than presenting our best-guess numbers with false confidence, we built a disclaimer system into every scheme card, every page, and the application receipt, each linking directly to the real official portal to confirm details. Avoiding a confidently-wrong chatbot. Early on we considered a general scholarship Q&A bot, but realized an LLM answering from general knowledge about exact income limits and deadlines would undermine the accuracy work we'd just done. We scoped the assistant to only see and discuss the user's own matched schemes, with explicit instructions to refuse anything outside that data. A real bug in the chat integration: the first message in any conversation was failing silently because our locally-generated welcome message was being included as a fake "assistant" turn sent to the API, which requires conversations to start with a user message. Caught and fixed it by excluding the seeded welcome line from what's actually sent. Scoping discipline. We considered adding a custom backend for "more legitimacy," and concluded it would add deployment risk without solving the actual bottleneck (verified live data), so we kept the architecture lean instead.

Accomplishments that we're proud of

A working eligibility engine across 49 real schemes with category, income, state, gender, and disability logic — tested against edge cases (zero matches, income exactly at the boundary, gender/minority exclusions) to make sure it's not just a demo-only happy path The "why you're eligible" reasoning, which only cites a criterion when it actually narrowed the match — so a scheme open to every category never falsely implies the student matched because of their category An honesty-first approach to a problem domain that's genuinely hard to verify automatically — we'd rather show a flagged, approximate number with a real source link than a confident-looking number we can't stand behind A chat assistant that's genuinely constrained, not just prompted to "be helpful" — it structurally cannot discuss scholarships outside what the student qualifies for

What we learned

That the hardest part of "AI for social good" projects is often not the AI — it's the data. We spent more effort deciding how to be honest about uncertain government data than we did on any single feature. We also learned that adding AI (a chatbot, a backend, more automation) isn't automatically an improvement — every addition has to earn its place by solving a real problem, not just making the project look more technically impressive.

What's next for Scholarship Navigator

Extend verified, source-linked data coverage from the central schemes to all 29 state schemes A renewal and deadline tracker, so students don't lose a scholarship by missing a renewal window Document upload and auto-fill, so paperwork gathered for one scheme carries over to the next Partnering directly with state scholarship cells to get authoritative, structured data feeds instead of relying on scattered public sources

Built With

• claude-api
• css3
• html5
• javascript
• localstorage