Across India, governments spend significant resources training frontline workers, including self-help group members and leaders, teachers, health workers, and community facilitators. Yet whether these trainings work is a question that rarely receives a structured answer.
Trainings are often conducted because programme mandates require them, and budgets are allocated based on institutional requests rather than evidence of what is needed most. What remains missing are feedback loops that can help institutions understand whether training translates into improved knowledge or practice.
Over the years, technology has frequently been positioned as the answer to this problem. Digital tools promised faster, cheaper, and more scalable data collection. But many of these tools have struggled in the contexts they were meant to serve. Tools such as Google Forms and Classmarker exist but they were built for contexts with stable connectivity and digitally confident users—assumptions that rarely hold in rural settings. We repeatedly encountered a wide gap between how a tool was designed and how an institution functioned. The problem is rarely whether a tool exists. It is whether it can be used by the people who need it, in the conditions they work in.
This is a problem we have worked on directly. Building Sashakt—an open-source assessment platform—taught us less about how to build a digital product and more about what it takes for technology to function as infrastructure within complex public systems. Government departments, nonprofits, frontline workers, and communities each operate differently, face different constraints, and relate to data differently. The challenge was not just building a working tool, but designing something that could operate across systems with very different realities and constraints.

The ‘tech-problem’ to solve
Veddis Foundation partnered with Tech4Dev to address this gap while working with the state and district teams under State Rural Livelihood Missions (SRLMs) in Haryana and Himachal Pradesh to strengthen how Cluster Level Federations (CLFs) used data and built capacity. CLFs are federations of self-help groups (SHGs), led by rural women, that act as a social, economic, and financial intermediary for their member SHGs.
Governments routinely fund training for these women in areas such as financial literacy, bookkeeping, and institutional management. However, there was no structured mechanism to assess whether these trainings were improving knowledge or strengthening institutional practices.
We initially experimented with paper-based and OMR-sheet assessments to address this gap. But at the scale of SRLM systems, the process quickly became unmanageable. In Haryana alone, more than 200 CLFs participated, making manual compilation and analysis operationally difficult.
The task at hand, though, was not simply how to conduct assessments digitally. While many commercial tools exist, we realised that they were built for different contexts and couldn’t be adapted to rural environments, low network connectivity, or government systems. What was needed was not a better tool. It was infrastructure—something institutions could absorb into how they already worked, and that others facing the same problem could adopt without having to build something new for their own context. That distinction shaped everything that followed.
As the platform was piloted across Haryana and Himachal Pradesh, many assumptions about how users would navigate digital tools quickly broke down.
What we learned from the field
When we took early versions of a digital assessment tool into the field, the gap between what we had built and what users could navigate became visible quickly.
Women trying to access assessments by scanning a QR code showed us how many steps we had assumed away. Opening the camera, pointing it at the code, waiting for it to load—these were not simple actions for users with limited prior exposure to smartphones. Many could not find the QR-scanning function without help. Others were confused by the consent screen and didn’t know how to start. Partially completed tests disappeared when users accidentally exited the browser. Older phones struggled to load assessments. Submissions reset unexpectedly. Users got error messages about unanswered questions after they had already answered them.
We partnered with FoldLabs, a research and design agency, and conducted field visits with SRLM officials and SHG members in Una district, Himachal Pradesh, to understand where people were getting stuck. We spent nearly two and a half months redesigning the entire product flow, user experience, and interface based on what we observed.
Apart from these product fixes, the field research brought out something more fundamental. In public and nonprofit systems, usability is not a layer you add after you have built functionality. It determines whether a product can function at operational scale at all—and whether institutions will integrate it. If a government official struggles to use the interface, the platform doesn’t get adopted. It doesn’t matter how robust the backend is.
Building for systems
The clearest thing that building Sashakt within the SRLM context taught us was that we couldn’t ask institutions to adapt to the tool. We had to design around how they already worked.
Assessments could be distributed through WhatsApp, a communication channel already embedded within CLF networks. State-level administrators could manage question banks and templates centrally, while district teams only needed to generate and circulate links. We reduced this process to a few clicks, since frontline workers were already stretched across competing priorities and couldn’t afford a tool that demanded more of their time. Results compiled automatically, eliminating the need for manual collation.
The platform was built for conditions that are easy to overlook when designing without taking field realities into account, such as inconsistent internet connectivity, older handsets, users with limited prior experience of digital interfaces, and situations where several people might share a single device. In some locations, connectivity was too unreliable for a straightforward online tool. The platform was designed to store responses locally and sync them once connectivity returned.
The platform had to function simultaneously for state-level administrators, district programme managers, nonprofits, trainers, facilitators, and participants taking assessments. Each had different needs, different levels of access, and different relationships to the data the platform produced. This shaped several core architectural decisions: role-based permissions, configurable assessments, tagging systems that allowed questions to be organised and reused across tests, reusable templates, and layered administrative controls that let state governments manage deployments without depending on the implementing team for every change.
The challenge deepened when Tech4Dev began speaking to organisations outside the SRLM context. Avanti Fellows, which supports students from low-income communities preparing for competitive exams such as JEE and NEET, had different requirements—more advanced question formats, education-specific assessment logic, configurations that made no sense for a CLF bookkeeping test but were essential for exam preparation. Designing for both contexts pushed the platform to accommodate a wider range of requirements.
Avanti Fellows wanted more advanced question formats such as match-the-following and other education-focused configurations. That is when we started asking whether the platform could become extensible enough to support different sectors and organisations.
This eventually informed a central design principle: The platform needed to remain generic enough to be reused across organisations while flexible enough to adapt to different operational needs.
Existing assessment platforms often lacked this adaptability. Some were closed-source; others were expensive or difficult to customise for rural and public-system contexts.
When a single tool became infrastructure
In late 2025, around 25,000 assessments were conducted across Haryana and Himachal Pradesh using Sashakt, covering approximately 430 CLFs. As patterns emerged from this data, we began redesigning its training approach—moving from generic assessments covering multiple themes to targeted, topic-specific tests administered immediately after training on that subject. If a CLF is weak in bookkeeping, it makes more sense to assess bookkeeping immediately after the relevant training rather than three months later through a combined test.
Over time, Sashakt began doing something beyond conducting assessments. The dashboards it generated—district-wise, topic-wise, role-wise—gave government and nonprofit staff a way to see patterns they had not previously been able to see. They made it possible to see which CLFs were struggling with bookkeeping, whether treasurers across a district understood loan documentation, and where training was landing—and where it was not.
We also began comparing assessment results with practical institutional indicators: loan disbursement quality, bookkeeping performance, and fund utilisation. CLFs that had received sustained support for over three years scored higher on these assessments, tests of financial literacy, bookkeeping, and institutional management, than those where interventions had begun recently. But the correlations should be read carefully. CLFs that are better organised and better resourced are likely to perform well on both assessments and operational indicators regardless of training.
The more significant shift was institutional. We were no longer just running digital assessments. We were generating evidence that could inform government conversations about training budgets and programme priorities.
Beyond the code
Generating evidence is only half the work. On the technical side, many nonprofits operate in areas with no connectivity, and making the platform fully offline-capable remains a work in progress. Tracking whether assessment-driven training happens is still a manual process and closing that loop digitally is the next problem to solve.
A tool that generates data no one acts on changes nothing. The value of the platform was not in the assessments it ran but in whether those assessments changed how decisions were made. That shift, from running assessments to generating evidence that institutions act on, is not guaranteed by the technology itself. It has to be built into how the work is designed from the beginning. Building Sashakt reinforced a simple lesson: technology is most useful when it becomes part of how institutions learn and adapt to take decisions. The real measure of success is not how much data a platform generates, but whether that data can help organisations allocate resources more effectively to strengthen their programmes. That is when a tool stops being just a piece of software and starts becoming infrastructure.
—








