Code for GovTech — C4GT '24 & '25

Two programs. Two domains. One question underneath everything.

C4GT — Code for GovTech — is a fellowship that places engineers in open-source civic and government technology projects. The shared premise is simple: public systems matter more than most software, they're usually built worse, and that's a solvable problem if enough people care to solve it.

I did two rounds.

OpenNyAI — C4GT '25

AI for legal access in India 5 months · Remote

India has a legal system that, on paper, covers everyone. In practice, navigating it requires a kind of literacy — legal, linguistic, financial — that most citizens don't have. OpenNyAI is trying to change that with AI tools built specifically for Indian legal contexts.

ML pipelines for legal document understanding

Built pipelines for question-answering over Indian legal documents — the kind of dense, archaic statutory text that doesn't yield easily to off-the-shelf models trained on English-language internet data.

The challenges were real: long and complex document structure, poor-quality OCR inputs, domain vocabulary with no clean training signal, and the requirement that answers be accurate enough to trust in a legal context. A hallucinated answer about someone's property rights is worse than no answer.

Multilingual NLP

India has 22 officially recognized languages. A system that only works in English is a system that doesn't work for most of India — including most of the people who most need legal help.

I enhanced NLP models for multilingual support, improving accessibility across the Indian languages that matter for actual legal access. This involved handling script diversity, low-resource language data, and building around the real distribution of users, not the convenient one.

Open-source AI for governance

Integrated open-source AI tools into governance workflows — building in a domain where the default instinct is to procure expensive enterprise software rather than ship well-chosen open-source models.

The work mattered precisely because it was open. A tool that any state government or legal aid organization can deploy and inspect is fundamentally different from one that runs on a vendor's servers.

eGov Foundation — C4GT '24

Civic tech infrastructure · Flutter · Mobile platforms Jun – Sep 2024 · Bengaluru / Remote

eGov Foundation builds the digital infrastructure that powers civic services in India — property tax collection, birth registrations, public works management. The scale is real: state governments, millions of citizens, and field workers who need software that actually works on mid-range Android devices in imperfect network conditions.

I joined as an SDE Intern on the mobile platform side.

Reusable packages for microservice architecture

Built Flutter packages that multiple products could share — the kind of work that doesn't look exciting in a ticket but matters at scale. When six products use the same package, a fix you ship propagates to all six. A bug you ship breaks all six. I treated that as a design constraint, not a footnote.

VoiceEnable accessibility feature

Many users of eGov products aren't comfortable reading and typing. Voice input closes a real accessibility gap — the difference between software that includes them and software that implicitly excludes them.

I integrated VoiceEnable as a first-class feature in the reusable packages, not a bolt-on. This meant designing for it upfront: state management, error handling, fallback behavior, and platform considerations from the start.

Speech recognition model evaluation

Tested multiple open-source speech recognition models against the package's real constraints: Android APIs, low-end hardware, Indian accents, noisy environments. Wrote the evaluation framework, ran the benchmarks, made the recommendation based on data rather than defaults.

Android speech API optimization

Worked directly with Android platform APIs to reduce latency in speech input. The gap between "I spoke" and "the app heard me" is the gap between a feature people use and a feature people abandon. I closed it.

BLoC state management fixes

Diagnosed and fixed data inconsistency issues in the BLoC structure of the packages. Quiet work. Nobody notices when state is consistent; they notice constantly when it isn't. I fixed it so the products built on top didn't have to work around it.

The question underneath

Two programs, two different domains, two very different codebases.

But the same question in both: what does it take to make software that works for people who can't afford for it not to?

Not "works in the demo." Works in production. Works on a low-end phone in a government office in a tier-3 city. Works for someone navigating a legal system in a language that isn't English. Works when the stakes are high enough that failure is a real cost to a real person.

That's the question I was trying to answer. Both times.