Laxshya

Bringing grounded AI financial guidance in Indian languages to families who need it most—making complex government schemes and long-term planning understandable and actionable.

Comment

Inspiration

Financial planning usually assumes that a person already knows what product to search for and what question to ask. Many Indian households begin somewhere very different:

  • “Can I do something meaningful with ₹100–₹500 a month?”
  • “What can I plan for my daughter's education?”
  • “How can I protect my family?”
  • “Is there government support for this immediate need?”

The schemes, Post Office infrastructure, public-benefit portals, digital accounts, and smartphones already exist. The missing layer is navigation: connecting an incomplete household need to a manageable set of relevant options, explaining the trade-offs plainly, and doing it in the person's language.

Laxshya began from the belief that financial inclusion is not only access to products. It is the ability to understand choices and start thinking in terms of goals. Its north star is the moment a household moves from an immediate question to a planning action: comparing quantified options, creating a named goal, or returning to refine it.

What it does

Laxshya gives the user four human entry paths:

  1. Plan — save toward a family goal.
  2. Protect — understand available insurance and protection options.
  3. Need — discover relevant government support.
  4. Guide Me — begin with an ordinary question without knowing a scheme name.

A common MongoDB-driven questionnaire asks only the relevant conditional questions. Its normalized answers and optional free text enter a backend Smart Router, which sends the request to the correct domain:

  • Post Office: curated scheme records and structured filtering in MongoDB, followed by deterministic calculations and GPT reasoning.
  • Government schemes: more than 4,600 MyScheme records normalized by an offline curation process and indexed in Redis. The question keys drive need, state, and special-persona indexes, narrowing the runtime set to at most 20 candidates before GPT returns and explains 3–5.

GPT-5.6 interprets incomplete context, ranks only the candidates supplied by the structured system, and explains why an option may fit. It cannot introduce a scheme outside the retrieved set. Known family-head information such as age can improve reasoning, but the system does not silently treat the family head as another beneficiary.

For deeper Post Office questions, Laxshya retrieves relevant chunks from curated source documents in Milvus and streams a grounded GPT-5.6 answer. MyScheme follow-ups deliberately remain lightweight: they use the selected or cached scheme data and direct the user to the official MyScheme page.

The model reasons in English for consistency. A separate Google Cloud Translation layer delivers the explanation across English and seven Indic languages. Tamagui, Next.js, and Expo provide one product experience across web, iOS, and Android.

Laxshya is a discovery, navigation, and planning aid. It does not claim government approval, guarantee eligibility or returns, or replace verification with the relevant official authority.

How we built it

Laxshya is intentionally not an unconstrained chatbot. Each responsibility is assigned to the system best suited to it:

  • MongoDB stores the common dynamic questionnaire and curated Post Office scheme records.
  • The Smart Router deterministically selects the recommendation, calculation, or follow-up handler and the correct data domain.
  • Redis stores the normalized MyScheme corpus and its navigation, state, and special-persona indexes.
  • Deterministic calculators own investment projections and rate-table mathematics.
  • Milvus + E5 embeddings retrieve evidence for Post Office document follow-ups.
  • GPT-5.6 through the OpenAI Responses API ranks bounded candidates, reasons over partial household context, explains trade-offs, and streams grounded follow-up answers.
  • Google Cloud Translation v2 carries English-first reasoning into the user's selected language.
  • Tamagui + Solito + Next.js + Expo share the product layer across web, iOS, and Android.
  • FastAPI, Celery, MongoDB, Redis, Milvus, MinIO, and etcd run as a Docker Compose system behind Traefik and Let's Encrypt on AWS Lightsail.

The complete runtime is hosted for judging. The repository includes production Compose, health checks, environment templates, focused tests, RAG indexing commands, data-migration guidance, and a judge-facing README.

Challenges we ran into

Noisy government metadata

The raw MyScheme corpus is too inconsistently categorized and minimally tagged to place directly in an LLM prompt. A separate offline curation layer normalizes it into 11 need domains, navigation paths, and a controlled special-persona vocabulary before Redis indexing.

Useful breadth versus false certainty

Early filtering can become overly restrictive when a family head is researching for someone who is not yet recorded. The solution was to retain known context for reasoning, preserve broad discovery when beneficiary facts are missing, and make the explanation conditional rather than inventing precision.

Multilingual consistency

Independent reasoning in each supported language produced an avoidable quality boundary. Laxshya instead connects strong English reasoning with a dedicated translation service, making the reasoning contract testable once while preserving language access.

Reproducing document retrieval

The previous operational RAG path retained unnecessary LlamaIndex assumptions. We built direct-PyMilvus collection creation, verification, and scheme-filtered search using the same E5 embeddings as runtime, then restored and tested the vector data in the hosted environment.

Turning a local multi-service prototype into a judge-testable product

The production deployment exposed failures that local development did not: build-time Next.js configuration, a missing translator dependency, a Docker API mismatch in Traefik, MongoDB documents with missing array fields, and prompt/retrieval behavior that needed runtime verification. Resolving these made the Build Week contribution materially larger than a provider-name change.

Accomplishments that we're proud of

  • Deployed a working HTTPS product rather than submitting only a local proof of concept.
  • Connected one simple household experience to two different retrieval engines without exposing that complexity to the user.
  • Reduced a 4,600+ government-scheme corpus to a bounded candidate set before runtime model reasoning.
  • Integrated GPT-5.6 into both recommendation and streamed Post Office follow-up paths while keeping model authority constrained.
  • Demonstrated dynamic MongoDB questions, Redis-backed government-scheme discovery, deterministic calculations, multilingual delivery, goal creation, and grounded Post Office follow-up in one product.
  • Made RAG indexing reproducible and validated the hosted Milvus collections with scheme-filtered semantic search.
  • Preserved one Tamagui product layer across web, iOS, and Android.
  • Documented precisely what existed before Build Week and what Codex and GPT-5.6 changed during it.
  • Took Laxshya from its private prototype state to its first external presentation.

What we learned

The strongest use of an LLM is not to replace every structured system. It is to connect those systems to incomplete human intent.

We learned that:

  • candidate quality matters more than prompt size;
  • the trust boundary—routing, allowed IDs, hard rules, calculations, and official verification—is part of the product, not backend plumbing;
  • beneficiary ambiguity is a real household-design requirement rather than merely missing profile data;
  • English-first reasoning plus a dedicated translation boundary is more consistent and testable than separate financial reasoning in every language;
  • a real deployment is an architectural test: it reveals assumptions that a local happy path hides;
  • Codex is most valuable as a persistent collaborator that can inspect the whole system, diagnose failures across layers, and preserve decisions—not just generate isolated code snippets.

What's next for Laxshya

The next milestone is not more schemes or a more elaborate chat interface. It is a focused assisted pilot.

We want to run one district-level pilot with a trusted distribution channel such as a CSC-like operator or Post Office-adjacent workflow and measure:

  • dynamic-journey completion;
  • movement from an immediate question to a named financial goal;
  • language parity and correction rates;
  • official next-step engagement;
  • repeat planning for another household goal or beneficiary.

Product hardening will focus on scheme-aware contribution calculations, an explicit RAG scheme-to-source coverage report, source/rate freshness, privacy controls, audit-friendly telemetry, accessibility, and streamlined mobile workflows. The long-term product is a household planning layer that helps communities compare options, commit to goals, return, and refine—not merely search a scheme catalogue once.

Built With

Share this project:

Updates