Building for Bharat

I'm writing this from the middle of it. Not looking back, not summarising. I'm currently a Build for Bharat Fellow, placed at the Centre for Smart Governance (CSG), Government of Karnataka. Working on DIALOG, deploying at ISRO and HRMS, building inference pipelines on an H200. This post is about how I got here and what I'm learning along the way.

How I got into CS

I started coding in 2020. Python for Everybody, CS50, the usual starting points. Hobby projects, breaking things, figuring out why they broke. I wrote about this in an earlier post: the satisfaction of getting something to work, the slow accumulation of understanding that comes from struggling through problems instead of copying solutions. By the time I enrolled in my undergrad for CS, I already knew I enjoyed this. The degree wasn't a default. It wasn't peer pressure, and it wasn't about the placement stats. I just wanted to build things.

The early undergrad years were a lot of building for the sake of building. A calculus-based portfolio optimizer. Random Python scripts. Agent systems. Every time something I built actually worked, there was a specific kind of satisfaction that nothing else matched. But after a while I started noticing a pattern: I was getting better at building, but I wasn't sure what I wanted to build for. The skills were compounding. The direction wasn't.

Finding the fellowship

Somewhere during my final year, someone posted the Build for Bharat Fellowship opportunity in a Code4Govtech group I'd been part of the previous summer. I hadn't heard of the fellowship before that. The deadline was close. They extended it to November 1, which is when I applied. I wouldn't be writing this post if they hadn't extended that deadline. The premise was simple: put young builders in front of real India's real problems. Not hackathon toys that get demoed once and abandoned. Actual governance problems, actual citizens, actual constraints. Budgetary, bureaucratic, infrastructural, linguistic. The kind of constraints that don't show up in a classroom and can't be simulated in a weekend sprint.

The application process itself was well thought out. It wasn't a resume drop and a cultural-fit call. There was an assignment, and the assignment was basically an intro to GovTech in disguise. We had to pull data from APIs on data.gov.in, which sounds straightforward until you actually try it. The APIs are inconsistently documented. Some endpoints return data in formats that don't match the stated schema. Rate limits are unpredictable. Error handling is, generously, sparse. This is the actual state of government data infrastructure. The assignment didn't abstract it away. It threw you into it.

The task was to build a system that pulls in this complicated, messy data, makes sense of it, and produces natural language responses based on it. A PoC, which is very much the GovTech way: prove the concept works before you commit resources to building the full thing. You don't get a greenfield microservices project on day one. You get a proof that something is possible, and then you scale from there. The assignment was structured exactly like that.

After the assignment, there was a tech interview round with Harsh Nisar, co-founder at BharatDigital and currently IT advisor to NHAI. A seasoned GovTech data scientist. The interview was refreshing because it wasn't about outputs. He didn't ask "what accuracy did you get?" or "how fast does it run?" He asked about architecture and approach. Why did you structure it this way? What happens when the data source changes? How would this scale if you're dealing with 50 APIs instead of 3? Real-life questions. The kind that matter when you're building systems that need to survive contact with actual government infrastructure, not just look good in a notebook.

I got in. And it's been a completely different kind of education since.

The Orientation

Before we got placed into departments, there was a 4-day orientation. 19 fellows, a mix of engineers and designers. This was, honestly, the single most important educational experience of the fellowship. Not because of the technical content. Because of the context.

Sessions were taken by people who've actually worked in and around GovTech for years. Not academics. Not consultants who've done a three-month engagement and wrote a whitepaper. People who've shipped systems used by government departments, navigated the bureaucracy, dealt with the failures. The sessions covered a range of things that you don't learn in engineering school and can't pick up from documentation.

GovTech landscape. What does the ecosystem actually look like? Who builds what? Where does NIC fit in? What do state-level bodies like CSG do differently from central agencies? What's the role of organisations like MeitY, NeGD, state IT departments? This sounds basic but it isn't. The government tech stack is not a single entity. It's a fragmented landscape with overlapping jurisdictions, and understanding the map before you start working in it saves months of confusion.

Navigating bureaucracy through tech. This was the session that made me realise building the software is maybe 40% of the job. The other 60% is understanding how decisions actually get made in government. Who signs off on what. How requirements flow from a policy decision to a GR to a department to an IT team to a vendor to an actual system. Where things get stuck. Why a perfectly good technical solution might not get adopted because it doesn't fit the procurement process or the sign-off chain. You can build the best system in the world, but if the section officer doesn't use it, it doesn't exist.

Handling the public. Government systems serve citizens, not users. The distinction matters. A "user" chose to use your product. A "citizen" has to. They don't have alternatives. If your portal is the only way to apply for a ration card, and it's broken, they can't just switch to a competitor. They wait. Or they give up. Or they go back to the physical office. Sessions on this covered accessibility in the real sense: language, literacy, device constraints, physical environment (using a phone in bright sunlight in a taluka office, for example). Not WCAG compliance checkboxes. Actual accessibility for actual people.

What works and what doesn't. Case studies from people who've been there. Things that succeeded and why. Things that failed and why. The pattern that came through consistently: technology is rarely the reason GovTech projects fail. It's usually requirements mismatch, vendor lock-in, lack of ownership after handover, or building something that works in a demo but doesn't survive contact with the actual department workflow. The failures are instructive. They're also more common than the successes.

Open source in government. Why open source matters in GovTech specifically. Vendor dependence is a huge problem in government IT: a department commissions a system from Vendor A, Vendor A builds it, Vendor A's contract ends, and now nobody inside the department knows how to maintain it. Open source, or at least open-standards and documented architectures, is a way out of that trap. Sessions on this covered licensing, contribution models, and the practical challenges of open-sourcing government code (procurement rules, security concerns, who maintains it).

The reason this orientation mattered so much is that it made the actual placement smooth. When I joined CSG, I wasn't walking in blind. I understood the org's place in the ecosystem. I understood why decisions were being made the way they were. I had a mental model for the bureaucracy, which meant I could focus on the engineering instead of spending the first month confused about why things work the way they do. That's not a small thing. Most people entering GovTech spend their first few months just figuring out the lay of the land. The orientation compressed that into four days.

How GovTech actually works (from what I've seen)

Here's what I didn't know before I started: government tech isn't one thing. It's not a monolith. It's a collection of departments, each with their own processes, legacy systems, vendor dependencies, and idiosyncratic rules. The Revenue Department handles leave differently from the Education Department. ISRO's inventory process looks nothing like HRMS's retirement flow. I wrote about this in detail: how DIALOG uses Form.io and Camunda to handle this via process variants, separate BPMN definitions per org, shared runtime. The point is, the variation is real and the platform has to absorb it.

Government procurement cycles are long. Requirements drift. A feature that was scoped in month one might get redesigned in month four because a new circular came in. This isn't dysfunction. It's the nature of policy-driven development. The requirements come from outside the engineering team, and they change for reasons that have nothing to do with software. Learning to build in that environment, where your code serves a process you don't fully control, has been one of the more valuable parts of this fellowship.

The people doing this work are also not what I expected. The image of government IT is usually some dusty server room with outdated software. Some of that exists. But the teams at CSG are doing genuine engineering: platform design, observability, template systems, deployment pipelines. Under real constraints. With real users depending on the output. The H200 I'm running inference on belongs to CSG. That's not typical fellowship placement hardware. The investment in infra is real.

What the fellowship is doing for me

I came into this fellowship knowing how to build. I'm leaving (well, not yet, I'm still in it) knowing how to build for something. The difference sounds small but it isn't. Before, I'd pick up a problem because it was technically interesting. Now I still do that, but I also ask: who does this serve? What happens if it breaks? What's the rollback plan? These aren't questions that come up in hobby projects. They come up when your deployment affects whether someone can access a government service.

The fellowship also gave me something I didn't expect: a peer group that thinks about technology differently. Not "what's the latest framework" or "what's trending on Hacker News." More like "how do you build a form that a section officer in a taluka office can actually use?" or "what happens to this workflow when the internet drops mid-submission?" The problems are grounded, specific, and real. The conversations reflect that.

I'm still figuring things out. This isn't a conclusion post. I'm in the middle of the fellowship, still learning, still making mistakes, still finding problems I don't know how to solve yet. But the direction is clearer than it was. I wanted to build things. I still do. Now I'm building them in a place where the output matters to people who'll never read this blog or know my name. That's a good place to be.