HaqSetu

logo
Home page in Hindi with chatbot helper
Eligible schemes
local documents storage

Testing instructions

Live demo: https://haq-setu-three.vercel.app

Phone number: +91 9999888800
OTP: 543210

Inspiration

India runs one of the largest welfare systems on Earth: 800 million eligible citizens, a budget north of $210 billion a year, and a huge chunk of it never reaches the people it's meant for. Not because they don't want it. Because the system is a maze.

The stat that started this whole thing: in one Jharkhand district, more than 80% of Dalit and OBC families had no caste certificate, so they couldn't apply for a single scheme meant for them. One missing paper, total lockout. Two-thirds of eligible widows in Delhi never claim their pension because nobody told them it exists. And the cruelest one, the one that made this feel urgent: 8 to 12% of already-approved scholarships never get paid out, killed by a misspelled name, an Aadhaar number not linked to a bank account, a typo'd IFSC code. The government said yes. The money still doesn't show up.

People aren't losing benefits because they're lazy or don't qualify. They're losing them to paperwork, silence, and bank-linking errors nobody warned them about. That gap is fixable, and groups like Haqdarshak and Benefits Data Trust have already proven it. We wanted to build the version of that idea that fits in a browser tab and needs no fieldworker on the ground to use it.

What it does

HaqSetu is a bilingual (Hindi/English), privacy-first web app that does three things for a low-income Indian family, in order:

Finds the schemes they're actually eligible for — NSAP pensions, NFSA ration, PM-KISAN, PMAY-G housing, Ayushman Bharat, PM Ujjwala, the Post-Matric Scholarship, PMMVY, MGNREGA — with an honest "may be eligible" verdict, a cited reason, and a running estimate of what it's worth in rupees a year.
Catches the paperwork mistake before it becomes a rejection. The documents page runs a rejection check against the person's actual papers: name mismatches across Aadhaar/bank/certificate, Aadhaar not seeded to the bank, dormant accounts, bad IFSC codes, stale income certificates, missing non-creamy-layer status on an OBC certificate. It hands back a readiness score and the exact fix for each problem, the same checks every time.
Tracks the claim until the money lands, not just until it's "approved" — because approval and payout are not the same thing, and that gap is where scholarships quietly die.

One profile, entered once, flows through all of it. A small assistant sits in the corner of every screen, answers questions in Hindi or English, can read its answers aloud, and opens on its own if someone's been stuck for a couple of minutes without touching anything, which is usually a sign they're lost, not browsing.

Nothing leaves the device. The whole thing runs in localStorage.

How we built it

The core architectural bet was deciding, on day one, what the AI is allowed to touch and what it's never allowed near. A language model's only job is translation: messy text in, structured fields out; a finished result in, plain Hindi or English sentences out. Every actual decision in between, eligibility, which document to get first, whether a bank account will reject a payout, runs through a deterministic rules engine we wrote and unit-tested ourselves.

            ┌─────────────────────────┐
            │     Person's input      │
            │  free text, Hindi/Eng   │
            └────────────┬────────────┘
                         │
                         ▼
            ┌─────────────────────────┐
            │     Language model      │
            │   structures the text   │
            │     into a profile      │
            └────────────┬────────────┘
                         │
                         ▼
   ╔═══════════════════════════════════════════╗
   ║              Rules engine                 ║
   ║      deterministic · unit-tested · cited   ║
   ║                                             ║
   ║   • Scheme matching    (11 schemes)         ║
   ║   • Entitlement graph  (best unlock path)   ║
   ║   • Rejection check    (name/IFSC/seeding)  ║
   ╚════════════════════╦════════════════════════╝
                         │
                         ▼
            ┌─────────────────────────┐
            │     Language model      │
            │   explains the result   │
            │   plain language, bi-   │
            │  lingual, no new facts  │
            └────────────┬────────────┘
                         │
                         ▼
            ┌─────────────────────────┐
            │   Person confirms it    │
            │    human at Gram        │
            │ Panchayat / CSC decides │
            └─────────────────────────┘

   (entire flow runs in-browser; only the two LM steps make an
    optional, consented call out to Gemini — the engine never does)

The double-bordered box is the only one allowed to actually decide anything. The model shows up before it and after it, purely as a translator: text to structured data going in, dry verdict to plain sentence coming out. It never gets a vote on eligibility.

A few pieces we're glad exist:

Adaptive intake that picks the next question by value of information. Instead of a 40-field form, it asks whatever single question would most change the answer, and stops asking once it knows enough.
An entitlement dependency graph that models schemes, the documents they require, and the documents those documents require, so it can compute the actual unlock path: get this one paper, and three schemes open at once.
A rejection check that's exact and repeatable, checking the same five failure points every single time, because that consistency is the entire value proposition over asking a chatbot.
Stack: Next.js, React, TypeScript, Tailwind, all free and open source. Google Gemini (gemini-2.5-flash, free tier) for the optional language features. Claude Code for AI-assisted coding, disclosed here as it was throughout the build.

Challenges we ran into

The hardest problem wasn't the AI part, it was resisting the AI part. It's genuinely tempting to let a language model just answer "am I eligible for PM-KISAN," and it'll sound confident doing it. But a model's confidence isn't the same as it being right, and being wrong about whether a poor family qualifies for a pension has real consequences. We had to keep pulling logic back out of the model and into code we could unit-test, even when the model version was faster to ship.

Designing for someone who has never used a chatbot was its own challenge. Icon-led intake, full Hindi from the first screen to the printed plan, and a working fallback path (a local keyword parser, a templated explanation) so the app never breaks if there's no API key, since the demo has to survive without depending on a key being present at judging time.

And scoping was a constant fight. It would've been easy to promise "every scheme in India" and deliver something shallow. We picked eleven major central schemes and two states (Rajasthan, Bihar) with real document detail, and said so plainly, rather than faking national coverage we hadn't actually built.

Accomplishments that we're proud of

Getting the rejection check to actually catch the failure modes that kill real applications, not generic "fill out this form correctly" advice, but the specific stuff that loses scholarships after approval: Aadhaar not seeded to a bank account, an IFSC typo, a name that doesn't match across three documents. That's the part of the system almost nobody builds for, because it's boring compared to "find my benefits," and it's also where a meaningful chunk of the actual money loss happens.

We're also proud the app survives without its AI key. Pull the Gemini calls out entirely and the rules engine, the document check, and the tracker still work end to end. That wasn't an accident; it was the design from the start, because a tool built for someone with no internet reliability or no API budget shouldn't quietly stop working.

What we learned

The biggest one: for a domain like welfare eligibility, the AI's job is to be a translator, not a judge. A language model is excellent at turning "meri maa ki umar 65 saal hai aur woh akeli rehti hai" into a structured profile, and excellent at turning a dry verdict into a sentence a person can act on. It is the wrong tool for deciding the verdict itself, because it can't promise the same answer twice and it can invent details under pressure to be helpful. Once we accepted that split, the rest of the architecture basically fell out of it.

We also learned how much of benefit exclusion is downstream of one document, not ignorance or apathy. Modeling that as a graph instead of a checklist changed the entire intake experience, because the first question to ask is almost never the one a long government form asks first.

What's next for HaqSetu

Expand past Rajasthan and Bihar into more states, since document processes and thresholds genuinely vary and that detail is the whole value of the tool.
Partner with or route directly into an existing human network, like a Common Service Centre or a Haqdarshak-style fieldworker, so the printable action plan has somewhere real to land instead of just being printed.
Add real phone-based OTP once there's budget for an SMS provider, so the demo account becomes a real account.
Build a lightweight way for Gram Panchayat staff or CSC operators to confirm a claim's actual status, closing the loop between "tracker says applied" and "money received" with something sturdier than the user's own update.