Inspiration

We started with a simple question.

Why do millions of people in India who are legally entitled to government welfare benefits never actually receive them?

Initially, the obvious answer seemed to be lack of awareness.

After researching India’s disability welfare ecosystem, we realized that diagnosis was wrong.

The problem is not awareness.

The problem is navigation.

A person with disability often has to search through fragmented government portals, manually interpret bureaucratic eligibility criteria, understand legal documents, and somehow figure out whether they qualify before even beginning the application process.

The system assumes the user already understands the system.

That is fundamentally broken.

That realization became SaralSeva.

Not another chatbot.

A system designed to make welfare access actually understandable.

What it does

SaralSeva is an AI-powered welfare navigator built specifically for persons with disabilities in India.

It helps users understand which government welfare schemes they are likely eligible for by analyzing their disability profile, financial background, education status, certification documents, and other eligibility factors.

The system accepts voice conversations, text-based interaction, and direct disability document uploads such as UDID certificates.

Instead of simply listing schemes, the AI reasons through eligibility conditions and returns personalized recommendations, confidence scoring, source-backed explanations, and a step-by-step action roadmap showing what the user should do next.

The goal is simple.

Turn bureaucratic complexity into clear action.

How we built it

Our first architecture was honestly overengineered.

We initially designed a much larger AI system involving vector databases, retrieval pipelines, agent orchestration systems, and multiple reasoning layers.

Then we asked a better engineering question.

Do we actually need any of this?

The answer was no.

Unlike open-ended search systems, welfare eligibility is structured logic.

Government schemes already define their rules.

Income thresholds.

Disability categories.

Education requirements.

State-specific conditions.

So instead of building a retrieval system, we redesigned the architecture around direct reasoning.

The system accepts user information through voice, text, or document upload.

Using multimodal AI, structured information is extracted directly from disability certificates.

Regional language voice input is processed through Sarvam AI speech pipelines.

The reasoning layer compares user context against structured scheme rules and generates personalized recommendations.

We built the frontend using Next.js, used Convex for state management and persistence, and built the AI pipeline around multimodal LLM reasoning.

Challenges we ran into

The biggest challenge was execution.

Like most engineering teams building under a hackathon deadline, our first instinct was to build far more than we realistically could.

Our original architecture included vector databases, multi-agent orchestration systems, retrieval pipelines, sign-language recognition, multiple AI workflows, accessibility layers, and a much larger reasoning system.

On paper, it looked impressive.

In practice, we realized we were building too many systems at once.

We had designed something technically ambitious, but not something we could confidently execute end-to-end within a seven-day build window.

That forced us to step back and rethink the entire architecture.

We removed large parts of the original system, cut unnecessary infrastructure, abandoned retrieval-based approaches, and redesigned everything around a much simpler reasoning pipeline.

In a way, one of our biggest failures during development was overengineering too early.

Another major challenge was responsible AI design.

This system operates in a high-impact domain where incorrect output can create real consequences.

If the AI incorrectly tells someone they qualify for a welfare scheme, that user may spend time collecting documents, physically travel to government offices, and eventually face rejection.

That is not a harmless hallucination.

Designing for reliability, uncertainty handling, and human verification became significantly harder than building the AI itself.

Ironically, the hardest part of building SaralSeva was not building the system.

It was learning how much of the system we needed to stop building.

Accomplishments that we're proud of

The biggest accomplishment was simplifying the system without reducing capability.

We moved from a highly complex architecture into a focused reasoning pipeline that directly solves the core problem.

We are also proud of designing the system around accessibility from day one.

Voice interaction.

Multilingual communication.

Document-first onboarding.

And human verification built directly into the reasoning flow.

Instead of building another generic AI assistant, we built a system solving a real-world problem that directly impacts vulnerable communities.

What we learned

The biggest lesson we learned is that good AI systems are rarely about adding more AI.

The hardest engineering decisions usually involve understanding what not to build.

We learned that solving real-world problems requires understanding system design much deeper than model selection or API integration.

More importantly, we learned that AI becomes genuinely valuable when it reduces friction in systems people genuinely depend on.

Sometimes removing complexity is the most important technical decision.

What's next for SaralSeva

The current version focuses on core welfare eligibility reasoning.

The next phase is expanding the platform into a full accessibility-first welfare infrastructure.

We plan to integrate more government welfare schemes across different states, improve multilingual support for regional languages, introduce document generation for application workflows, and build a stronger human verification network connecting users directly with welfare officers and support organizations.

Long term, we see SaralSeva becoming far more than a benefits navigator.

We see it becoming the infrastructure layer that makes public welfare systems actually accessible for the people they were originally built to serve.

We are not building another assistant.

We are rebuilding access to welfare itself.