We Built Kisan Scheme Saathi in 24 Hours: Our Hackathon Journey, 3 AM Bugs, and Lessons from the Judges

In rural Karnataka, accessing government welfare schemes can be difficult for the farmers who need them most.

Although several government initiatives provide agricultural subsidies, irrigation support, crop insurance, and educational scholarships, many smallholder farmers struggle to access these benefits because of:

1. Complex government documents written in difficult administrative language.
2. Scattered government portals, including Bhoomi, FRUITS, PM-KISAN, and Samrakshane.
3. Dependence on intermediaries, sometimes involving unnecessary charges.
4. Language and digital literacy barriers on conventional government websites.

During a challenging 24-hour hackathon, our team set out to address this problem by building Kisan Scheme Saathi (ಕಿಸಾನ್ ಸ್ಕೀಮ್ ಸಾಥಿ) — an open-source, voice-first web application designed to help farmers discover relevant government schemes, understand eligibility requirements, view document checklists, and track important deadlines.

🌐 Live Website: Kisan Scheme Saathi

📂 GitHub Repository: Kisan Scheme Saathi

📜 License: MIT Open Source License

We didn't win the award. But we gave the hackathon everything we had. We built a working product, dealt with unexpected technical challenges, fixed late-night bugs, disagreed over architectural decisions, and faced questions from judges that made us rethink parts of our solution.

This is the story of those 24 hours — the decisions, challenges, mistakes, and lessons we took away from the experience.

The Kisan Scheme Saathi landing page, designed to make the platform accessible through a simple, bilingual interface.

🎯 Why We Started with Karnataka

When the 24-hour countdown began, our initial ambition was huge:

"Let's build a unified government scheme matcher for all 28 states of India in 12 languages!"

But within the first two hours, we realised that this approach was too ambitious for the time available.

Agricultural schemes and eligibility requirements vary significantly between states. Karnataka also has its own digital infrastructure and welfare programmes, including:

• Bhoomi RTC / Pahani: Land record and ownership information.
• FRUITS FID: Farmer Registration and Unified Beneficiary Information System.
• Samrakshane Portal: An important platform for crop insurance-related services.
• State-specific welfare schemes: Programmes such as Ganga Kalyana, Raitha Siri, and CM Raitha Vidyanidhi.

We had to make a practical decision: instead of building a broad but shallow application, we would focus on Karnataka and make the experience more meaningful for its farmers.

┌─────────────────────────────────────────────────────────────┐
│                    THE HACKATHON REALITY                    │
│                                                             │
│   Build for 28 States without enough depth   ❌             │
│   Focus on Karnataka with greater detail     ✅             │
│                                                             │
│   • Schemes: 8 Central and Karnataka programs               │
│   • Languages: Kannada (ಕನ್ನಡ) and Indian English           │
│   • Architecture: Designed for future expansion             │
└─────────────────────────────────────────────────────────────┘

Because of the strict timeline, we focused on Karnataka farmers, supporting Kannada (kn-IN) and Indian English.

However, we designed the underlying rules engine and JSON data structure with future expansion in mind. The architecture can be extended to other states by adding their respective schemes, eligibility rules, and regional requirements.

🥊 The War Room: A Debate That Shaped Our Architecture

Hackathons are not just about writing code. They also test how a team makes decisions under pressure.

Around the third hour, we had a major disagreement about how the eligibility system should work.

• Camp A — The AI-first approach: "Why write complex eligibility logic? Let's send the farmer's details to an LLM and ask it to identify the eligible schemes. We can build that quickly!"
• Camp B — The reliability-first approach: "What if the AI generates an incorrect eligibility rule? A farmer might spend time and money visiting an office based on that information. We cannot take that risk."

The discussion helped us arrive at an important architectural decision:

1. Deterministic eligibility evaluation: Scheme qualification would be handled through predefined rules and application logic, using details such as landholding, irrigation type, category, and crop information.
2. AI-assisted explanations: Google Gemini would support conversational explanations, helping users understand why a scheme might or might not apply to them.

In short, we decided that AI could help explain the results, but the core eligibility decision should come from explicit rules rather than an LLM-generated answer.

Once we agreed on this approach, we divided the responsibilities and continued building.

🐛 The Battles in the Trenches: 3 AM Bugs and Engineering Challenges

Building a working application in 24 hours meant dealing with problems we had not initially anticipated. Some of our biggest challenges appeared during testing.

1. The 3:15 AM Kannada Voice Synthesis Crisis

We wanted Kisan Scheme Saathi to be accessible to farmers who might find reading long instructions on a screen difficult.

The application therefore needed to support both voice input and audio responses.

Initially, we tried the browser's native Web Speech API. It worked during our English tests, but Kannada (kn-IN) presented problems.

On our testing setup, the browser did not consistently provide a suitable Kannada voice. Some attempts failed, while others produced unnatural pronunciation.

We needed a more reliable solution.

// Integrating Murf AI for Kannada voice output
// Configured Kannada voice options for the application

export function getMurfDefaultConfig() {
  return {
    voiceId: 'Harman',       // Male Kannada voice
    femaleVoiceId: 'Pooja',  // Female Kannada voice
    locale: 'kn-IN',
    model: 'Falcon 2.1'
  };
}

We integrated Murf AI Falcon 2.1 for Kannada text-to-speech, using the configured voice options to generate audio responses.

Alongside Murf AI, we integrated Deepgram Nova-2 for speech-to-text. This allowed farmers to speak details such as their landholding and crop information through their phone's microphone.

We also implemented a custom phonetic transliteration fallback, transliterateKannada, to help handle regional agricultural terms such as Pahani, Bhoomi, and Raitha.

This was an important step towards making the application more accessible to users who prefer speaking rather than typing.

2. The Village Connectivity Reality: Building an Offline Caching Database

Many web applications are developed and tested using reliable internet connections. But connectivity in rural areas can be inconsistent.

We wanted Kisan Scheme Saathi to remain useful even when a farmer experienced slow network speeds or temporary connection failures.

Imagine a farmer clicking "Check My Eligibility" and waiting several seconds for a remote database request. If the application appears unresponsive, the farmer may simply leave.

To address this, we worked on an offline-first caching database architecture.

┌────────────────────────────────────────────────────────┐
│             VILLAGE CONNECTIVITY REALITY               │
│                                                        │
│   City: 5G / Fiber Optic  ──> Better connectivity      │
│   Village: 2G / Edge      ──> Unstable connectivity    │
└────────────────────────────────────────────────────────┘

Our implementation included:

• Caching scheme rules, document requirements, and district mappings to reduce repeated server requests.
• A dual-mode persistence mechanism using pgPool.ts.
• A local JSON fallback at data/app-db.json when the PostgreSQL database was unavailable.

Here is an example of the backend test output during a run where the local JSON fallback was activated:

> [email protected] test
> npx tsx tests/integration.test.ts

[TEST SUITE] Importing and starting Kisan Scheme Saathi server...
[PostgreSQL] Database not reachable. Using local JSON fallback (data/app-db.json).
Kisan Scheme Saathi backend running on http://localhost:5000

======================================================
   RUNNING COMPREHENSIVE BACKEND API TEST HARNESS
======================================================
  ✓ [PASS] Health Check (/api/health)
  ✓ [PASS] Schemes Catalog (/api/schemes)
  ✓ [PASS] Scheme Details (/api/schemes/pm-kisan)
  ✓ [PASS] Document Checklist (/api/schemes/pm-kisan/checklist)
  ✓ [PASS] Application Guide (/api/schemes/pm-kisan/application-guide)
  ✓ [PASS] Eligibility Engine (Marginal SC Millet Farmer)
  ✓ [PASS] Eligibility Engine Output Distinction (Large General Sugarcane Farmer)
  ✓ [PASS] Conversational Chatbot Endpoint (/api/eligibility-chat)
  ✓ [PASS] Chatbot Input Validation: Reject "I don't know" for Name
  ✓ [PASS] Chatbot Input Validation: Reject Invalid Age
  ✓ [PASS] Chatbot Confirmation: Aadhaar advances to Confirm Step
  ✓ [PASS] Chatbot Confirmation: No/Change routes to Edit Options
  ✓ [PASS] Chatbot Confirmation: Yes Evaluates Schemes
  ✓ [PASS] Farmer Registration & OTP (/api/auth/register)
  ✓ [PASS] Verify OTP & Issue JWT (/api/auth/verify-otp)
  ✓ [PASS] Unregistered Mobile Login Block (/api/auth/send-otp LOGIN_VERIFICATION)
  ✓ [PASS] Unregistered Mobile Verify OTP Block (/api/auth/verify-otp LOGIN_VERIFICATION)
  ✓ [PASS] Registered Mobile Login Verification (/api/auth/send-otp & verify-otp)
  ✓ [PASS] Check User Database Endpoint (/api/auth/check-user)

======================================================
TOTAL SUITE RESULTS: 19/19 PASSED (100%)
======================================================

The test run reported 19 out of 19 checks passing, including the database fallback, eligibility engine, chatbot, and authentication flows.

Although we implemented a local JSON fallback when PostgreSQL was unavailable and worked on caching frequently accessed scheme information, this did not mean that the entire application was fully functional offline. The fallback improved backend persistence resilience, while caching helped reduce repeated requests. Full offline functionality remains an area for future improvement.

3. The Big Bug: Accepting Invalid User Input

Around 5:30 AM, while testing different user journeys, we discovered an important validation issue.

The application was accepting input without sufficiently checking whether the values were valid.

For example, a user could enter:

• Landholding: -50 acres or random letters.
• Phone number: 123 or 99999999999999.
• Social category: left unselected.

This could lead to incorrect eligibility results. A user entering a negative landholding value, for example, could be processed by the rules engine without the expected validation.

We paused other development work and spent considerable time strengthening the validation layers.

The changes included:

• Validating phone numbers to accept 10-digit Indian mobile numbers, with checks across onKeyDown, onPaste, onInput, and regex validation.
• Restricting landholding inputs to positive numeric values within the application's configured range.
• Adding step-by-step confirmation in the conversational chatbot so that user details are checked before the eligibility evaluation begins.

This experience reminded us that input validation is not just a technical detail. When an application deals with government benefits, incorrect input can lead to misleading results.

The matched schemes dashboard showing scheme information, Kannada audio controls, deadline indicators, and relevant application links.

🔔 Smart Scheme Reminders: Helping Farmers Never Miss a Deadline

Finding an eligible government scheme is only the first step. Farmers also need to know when applications open and when deadlines are approaching.

Some schemes have specific application windows and seasonal deadlines. Missing these dates could mean losing an opportunity to benefit from a scheme.

To address this challenge, we designed the My Reminders feature in Kisan Scheme Saathi.

Farmers can explore eligible and upcoming schemes and use the Set Reminder option to keep track of important application dates.

Our Vision for SMS Notifications

As part of our proposed reminder functionality, we plan to introduce SMS notifications that can:

1. Notify farmers when an upcoming scheme application window opens.
2. Remind farmers before an application deadline.
3. Provide timely alerts so they can prepare the required documents and apply.

Why This Feature Matters

• Avoid Missed Deadlines: Help farmers keep track of important application dates.
• Stay Informed: Make upcoming scheme opportunities easier to follow.
• Timely Action: Remind farmers to prepare and submit applications before deadlines.
• Accessibility: SMS notifications can reach farmers directly through their mobile phones without requiring them to repeatedly visit the website.

The SMS notification functionality is part of our planned enhancement and was not active in the hackathon implementation.

Our goal is simple: Helping farmers discover the right schemes is important, but helping them act at the right time is equally important.

The My Reminders interface, designed to help farmers track upcoming scheme application windows and important deadlines.

📱 Mobile-First UX: Designed Around How Farmers Access Technology

One important question we considered while designing Kisan Scheme Saathi was: How will farmers actually access this platform?

For many farmers, a smartphone is one of the most accessible ways to connect to digital services. Rather than expecting users to visit a computer centre or navigate a complicated desktop website, we wanted them to access scheme information directly from a device they already use in their daily lives.

That is why we prioritised a mobile-first, responsive user experience.

Our design focuses on:

• Responsive Layout: The interface adapts to different smartphone screen sizes.
• Simple Navigation: Important features are easy to find, with fewer unnecessary steps.
• Readable Scheme Information: Eligibility details, benefits, deadlines, and document requirements are presented clearly.
• Kannada Voice Interaction: Users can provide information through voice input and listen to responses in Kannada.
• Touch-Friendly Controls: Buttons, forms, and interactive elements are designed for convenient mobile usage.
• Easy-to-Understand Scheme Cards: Matched schemes are displayed in a structured format, helping users understand their options and next steps.

Our intention was not simply to shrink the desktop website to fit a mobile screen. We wanted to create an experience that feels natural and practical for farmers using smartphones.

Mobile interface of Kisan Scheme Saathi, demonstrating its responsive layout and farmer-friendly design.

🔐 Protecting Farmer Information: OTP-Based Authentication

While building a platform that handles personal information, we understood that accessibility alone was not enough. The security and privacy of farmers' data also had to be considered.

Farmers may provide personal details while registering and checking their eligibility for government schemes. We therefore implemented an OTP-based authentication system to help protect access to user accounts.

Our authentication flow includes:

1. Mobile Number Registration: Users register using their mobile number.
2. OTP Verification: A one-time password is sent to the registered mobile number.
3. Account Verification: Users must enter the correct OTP before their account can be verified.
4. JWT-Based Authentication: After successful verification, the backend issues a JSON Web Token (JWT) for authenticated access.
5. Login Verification: Login verification checks help prevent unregistered mobile numbers from accessing protected account functionality.

This approach provides an additional layer of account security while keeping the login process familiar and straightforward for mobile users.

We wanted the authentication experience to remain simple without overlooking the importance of protecting personal information.

Our design principle was simple: make the platform easy to access, but ensure that access to personal accounts is verified.

🏛️ The Three Rounds of Judging: Three Different Experiences

Hackathon judging was one of the most memorable parts of our experience.

We went through three evaluation rounds, each with a different judge. Every round brought a different experience, and some of the questions challenged us more than we expected.

┌───────────────┐     ┌───────────────┐     ┌───────────────┐
│    ROUND 1    │     │    ROUND 2    │     │    ROUND 3    │
│   (Judge A)   │     │   (Judge B)   │     │   (Judge C)   │
├───────────────┤     ├───────────────┤     ├───────────────┤
│ The Slang &   │     │ The Silent    │     │ Total         │
│ Paan Question │     │ Stone Wall    │     │ Redemption    │
│  (Went Blank) │     │ (No Feedback) │     │ (Impressed!)  │
└───────────────┘     └───────────────┘     └───────────────┘

Round 1: The Slang and Paan Curveball

The first judge arrived at our table. We presented our idea, demonstrated the Kannada voice features, and explained the deterministic scheme-matching system.

Then came a question we were not prepared for:

"This voice recognition is nice. But what about the regional slangs? The Kannada spoken in Hubballi-Dharwad is totally different from Mandya, Kalaburagi, or Mangaluru Kannada. And what if a farmer is chewing paan (gutka/tobacco) while speaking into the microphone? How will your AI understand muffled speech?"

We went completely blank.

Regional dialects? Muffled speech? We had integrated Deepgram and Murf, but we had not trained a dedicated speech model for these real-world conditions.

For a few moments, we struggled to come up with a convincing technical answer.

After the round, we thought more carefully about the question. We realised that supporting Kannada is not simply about selecting a language option in an API. Real-world speech includes regional accents, local vocabulary, background noise, and differences in pronunciation.

One possible direction is to conduct on-ground surveys with college students and local volunteers across different taluks. The collected speech samples could help us understand regional variations and explore the development of more suitable speech models.

It was a difficult question, but it exposed an important limitation in our original approach.

Round 2: The Silent Stone Wall

The second judge arrived, and we presented our application again.

We explained the offline caching approach, demonstrated the four-step eligibility wizard, and showed the document checklist for Grama One centres.

She listened quietly, nodded a few times, wrote notes on her evaluation sheet, and left without asking any questions.

We were confused.

Did she like the project? Was something missing? Did we fail to explain an important feature?

We still don't know what she thought about the presentation.

In a hackathon, direct feedback gives you something to work with. Silence can be much harder to interpret.

We felt that our difficulty answering the first judge's question, combined with the lack of feedback in the second round, had affected our confidence going into the final evaluation.

Round 3: Total Redemption

By the third round, we had decided to approach the presentation differently.

Instead of waiting for questions, we began by explaining the practical challenges a platform like ours would face in rural areas.

We addressed:

• Regional Kannada dialect variations.
• Background noise and unclear speech.
• Unstable internet connectivity.
• Incomplete documentation at service centres.
• The importance of reliable eligibility calculations.

We explained how our caching approach addressed connectivity challenges, why the eligibility engine relied on deterministic rules, and how future field surveys could help us improve regional speech support.

Then we demonstrated the working application:

• Spoke into the microphone in Kannada.
• Generated matching schemes, including PMKSY micro-irrigation, Ganga Kalyana, and Raitha Vidyanidhi.
• Played the Kannada audio responses.
• Demonstrated deadline countdowns and document checklists.

This time, the presentation went much better.

The judge engaged with our architecture, asked questions, and appreciated the effort we had put into understanding the practical challenges faced by farmers.

We walked out of the third round feeling much more confident.

🏆 We Didn't Win the Award, But We Gave It Our Best

When the final awards were announced, our name wasn't called.

Of course, we were disappointed.

We had spent 24 hours working with very little sleep, dealt with unexpected bugs, made difficult technical decisions, and put everything we had into the project. Naturally, we wanted to win.

But as we packed our bags and looked at the working Kisan Saathi application running on our phones, we realised that the experience had given us something valuable.

• We had built an application focused on a real problem faced by farming families.
• We had learned to think about low-connectivity environments and caching.
• We had understood why deterministic logic matters in applications involving eligibility decisions.
• We had experienced the importance of input validation, testing, and clear communication.
• We had received questions that helped us identify areas where our solution needed improvement.

We didn't take home the trophy, but we left with practical experience, technical lessons, and a clearer understanding of what it takes to build something useful.

🗺️ What's Next for Kisan Scheme Saathi?

The hackathon was only the beginning. We have several ideas for improving and expanding the platform.

Our roadmap includes:

1. Expanding Beyond Karnataka: Extending the application to states such as Maharashtra, Andhra Pradesh, Telangana, Punjab, and Uttar Pradesh, with support for their regional schemes and languages.
2. On-Ground Dialect Surveys: Working with student volunteers and local communities to collect regional speech samples and better understand rural language variations.
3. WhatsApp and IVR Voice Channels: Exploring ways to make scheme information accessible through WhatsApp voice notes and phone-based services, including for people using basic mobile devices.

Our long-term goal is to make government scheme information easier to understand and access, regardless of a user's language or internet connectivity.

🔗 Project Links and Source Code

• 🌐 Live Website: Kisan Scheme Saathi
• 📂 GitHub Repository: Kisan Scheme Saathi
• 📜 License: MIT Open Source License

💻 Tech Stack

Here are the technologies and services we used to build the application:

• Frontend: React 18, Vite 5, Tailwind CSS v3, Lucide Icons
• Voice and AI: Deepgram Nova-2 (Speech-to-Text), Murf AI Falcon 2.1 (Kannada Text-to-Speech), Google Gemini (Conversational Assistance)
• Backend: Node.js, Express, TypeScript, with a Spring Boot 3.4 Java module
• Storage and Caching: PostgreSQL 14+ with a local JSON caching fallback

🌾 Final Thought

If you're participating in a hackathon, don't focus only on building something impressive for the judges.

Try to build something meaningful for people whose problems are often overlooked by technology.

Our experience with Kisan Scheme Saathi taught us that a project does not have to win an award to be worth building. Sometimes, the most valuable outcome is discovering a real problem, attempting to solve it, learning from your mistakes, and understanding what needs to improve next.

Technology is at its greatest when it has mud on its boots.

Kisan Scheme Saathi is an open-source project licensed under the MIT License.

If you enjoyed reading about our journey, feel free to leave a ❤️, 🦄, or comment below.

Have you ever faced an unexpected question during a hackathon presentation? We'd love to hear your experience!