Government & Public Sector

Government software is a harder job than any business product, and it is not because of size. It is that the user cannot choose another provider, may not own a smartphone or read English, and cannot be turned away because their case is awkward. A citizen service portal that works well for a confident city user but fails the elderly pensioner in a Tier-3 town has not succeeded. It has only moved the exclusion online. Everything about how we build for the public sector follows from that.

Identity, payment and documents are national rails now

India has built world-class public digital systems, and the job is to use them the right way, not build them again. Aadhaar login and e-KYC for identity, with clear consent and the privacy protection the law requires. DigiLocker, so a citizen shows an issued certificate instead of uploading a photocopy nobody can check. UPI for fee collection, because it is the payment rail every citizen already trusts. API Setu for sharing data between departments, so a citizen is not asked for a document that another part of government already holds. Used well, these turn a twelve-document, three-visit process into a single online form. Used carelessly, they become a new weak point, so we build each one with a backup for the citizen whose Aadhaar login fails on the day.

Accessibility is a legal and moral requirement, not a nice-to-have

The Guidelines for Indian Government Websites and the RPwD Act make accessibility a legal duty, and WCAG is the standard we can measure it by. But real accessibility in India goes further than a screen-reader check. It means many languages, so the citizen reads the form in their own language, not just English or Hindi. It means screens that work on a low-end phone over a 2G connection. It means easy-to-read text and clear steps for users who are not sure with digital tools. And it means help from a person — a Common Service Centre operator or a help desk — for the citizen who truly cannot do it alone. We build to WCAG and GIGW from the first sprint. Adding accessibility later costs more and, done late, is never quite honest.

Grievance redressal and workflow are the actual product

Most e-governance is, underneath, a set of steps. An application is sent in, passed to the right officer, moved through set stages with set timelines, escalated if it stalls, and closed with a result the citizen can see. Complaint handling has the same shape, and it is where public trust is most directly won or lost. We build workflow engines where the process is set in settings, not fixed in code, because government processes change with every notification. Each stage has an SLA clock, a late stage escalates automatically, and the citizen can see everything, so they are never left wondering whether their file is moving. A complaint that disappears into an inbox is worse than no portal at all.

Audit trails, RTI and the assumption of scrutiny

Public systems face close checking in a way private ones rarely do. Every decision, every change of status, every look at a citizen's record has to be logged in a trail that can only be added to. An official with system access cannot quietly change it, because that trail is what answers an RTI request, a CAG audit, or a court. RTI itself is a set of steps with legal timelines and set appeal stages, and it should be built that way, not tracked in a register. Data protection under the DPDP Act applies to government too, with its own exceptions. Access by role, giving each person only what they need, is not optional when the data belongs to every citizen. We build assuming the system will one day be checked line by line, because sooner or later, it will be.