State scholarship portal re-engineering
A scholarship that is approved but not credited has not been given to anybody.
A state social-welfare department's scholarship portal is how hundreds of thousands of students actually receive what the law promises them. We are re-engineering one end to end — not a facelift on the old system, but a fresh suite of applications for every user it serves, from the student filling in a form to the minister reading the dashboard.
The problem domain
Legacy government portals accrete: each year's rules bolted onto last year's code until the system is the constraint on the policy. A scholarship pipeline runs from student application through institutional verification, departmental scrutiny and treasury disbursement — and every stage has its own users, its own failure modes, and its own queue of citizens waiting on it.
Three properties make this class of system harder than its screens suggest. The load is violently seasonal: nothing happens for months, then an application window opens and the entire cohort of a state arrives inside a fortnight, frequently on the last two days of it. The eligibility rules are not code the department owns — they are policy, revised annually, and they must be applied to past years exactly as those years defined them. And the last mile is a bank transfer, which is where the real failure lives: an approval that cannot be credited because a beneficiary's account details do not match the identity attached to the claim is, from the student's point of view, no scholarship at all.
What we're building
A dedicated application per audience
- Students — application, tracking and grievance in one place.
- Institutions — verification and roll management for the colleges and schools in the chain.
- Government officials — scrutiny, approval and workflow across the department's tiers.
- PFMS integration — disbursement wired to the government's public financial management system.
- Bureaucratic and ministerial dashboards — the state of every scheme, visible to the people answerable for it.
One rulebook underneath five surfaces
The five applications look nothing alike and must not disagree with each other by so much as a rupee. That argues for eligibility, scheme definitions and status transitions living in one versioned rulebook that every surface reads from, rather than being reimplemented per screen — which is the specific way portals of this kind usually rot.
Auditable by default
Public money creates an obligation that private software rarely carries: every approval, rejection and disbursement has to be attributable to a person and a rule, years after the fact, to an auditor who was not in the room. That requirement is cheap if it is built in from the start and close to impossible to retrofit — so it is in the foundation of this build.
Most of what we build is under NDA — yours would be too, unless you told us otherwise. Send the requirement and you get back a functional specification, at no charge.
Public sector · India
Large-scale citizen services platform
A high-volume public services platform architected around verification before disbursement rather than audit afterwards.
Read
Student transport · United States
Student transport development: two apps, two portals and an automated trip builder
Parent and driver apps, school-district and franchise portals, and an automated trip builder that routes and prices shared trips across several school districts — apportioned to the cent.
Read