Building the Gram Samriddhi Portal: Where It All Started

Every freelancer has a first real project. This is mine, and it did not start as a project at all. It started as a favour.

In 2024 I won Technovate, my college's technical fest. Not long after, my professor got a phone call: Amit Ghosh, the founder of Aaharan Edu Smart, needed a Figma UI/UX designer. My professor gave him my name. So I designed the interface in Figma — for free, because that is how these things begin — and figured that was the end of it.

A week later they called back. They liked the design enough to want the real thing: could I build the actual frontend application, for a demo to government officials? I built it. I got a lump-sum payment. And this time I really did think that was the end of it.

Then, six or seven months later, a third call. They needed the whole application — production-ready, launch-ready — for the Gram Samriddhi Yojana. I built it in a week. They were happy. I got paid in full. And a favour for a professor had quietly turned into the project that started my career.

What GSP actually is

The Gram Samriddhi Portal is a KPI monitoring system for the government of Tripura — the digital nervous system for tracking how development schemes are actually performing on the ground, block by block.

It is built as a strict three-tier hierarchy, because that is how the government itself is shaped:

• Block users submit their monthly KPI numbers — real schemes like Jal Jeevan Mission tap connections, household toilets, Anganwadi water access.
• District admins review and approve (or send back) the submissions from the blocks assigned to them.
• State super-admins sit on top with rankings, oversight, analytics, and user management.

On top of all that sits a set of public dashboards — anyone can see how the state is performing, without logging in. Transparency as a feature.

Building like the government audits you

You cannot build a government portal the way you build a side project. Someone is eventually going to run a security audit against it, so I built for that from the start.

Auth lives in httpOnly access and refresh cookies — never in localStorage where a script could read it. There is CSRF protection via double-submit tokens, Turnstile CAPTCHA on the sensitive entry points, rate limiting backed by Redis so it holds up across multiple processes, and the usual but non-negotiable hardening — helmet headers, XSS sanitization, bcrypt-hashed passwords, Zod-validated inputs. The whole thing runs self-hosted on a VPS behind Nginx, because a government portal owning its own infrastructure is part of the point.

Express, Prisma, and PostgreSQL on the back; React, Vite, and role-aware dashboards on the front. Boring, hardened, and deliberately so.

The three hard things

Cache validation. The public dashboards are heavy — lots of aggregation across districts and blocks — and they get hit by anonymous traffic, so they have to be cached hard. But cached data that goes stale the moment an officer submits a new number is worse than no cache at all. Getting the balance right — fast public reads that still reflect fresh submissions — was the single most technically finicky part of the build.

Account management for government users. Officials are not power users, and they should not have to be. A lot of design time went into account and role management that assumes the person on the other side is not going to follow the slickest modern flow — no clever gestures, no hidden affordances, just clear, forgiving screens that work the way a busy officer expects them to.

Shifting requirements. And then the honest one: the goalposts moved, often and suddenly. Auth needed to move to a different page. Ten new KPIs appeared out of nowhere. Features got added and dropped between calls. Early on that whiplash frustrated me — until I understood it is simply what building for a fast-moving startup and a government client at the same time feels like. Both move at their own pace, and neither waits for your architecture to be ready. The lesson was not to resent the changes but to build systems loose enough to absorb them, and to stop treating any requirement as final until it shipped.

Where it stands

Right now GSP runs on my server. The work order — the formal government go-ahead to host it on official infrastructure and run it through a security audit — is expected around August. Until then it is complete, live on my hardware, and waiting for the paperwork to catch up. Honest status: done and proven, pending its official home.

Why this one matters most

Technically, GSP taught me more than anything I had built before it — security you cannot fake, caching you cannot hand-wave, and requirements you cannot pin down. But its real significance is simpler.

This is the project where a free Figma file became a paid frontend, became a launched government application, became a career. It is the reason there is a portfolio here at all. And nearly every project on this site can trace a line back through it — the same client came back for more, referred me onward, and the work kept compounding from that one phone call my professor answered.

That is the whole thesis of how I work: do the first thing well, even for free, and let it become the next thing.