Deep dive
How I kept the pilot free — and ready to grow
Every optimisation I made to keep the pilot on the free plan, and why each one works for this app in particular.
Project 02 · Civic tech · [20XX]–present
Gaav Tithe Sau
A welfare scheme is only as good as the last village it reaches. This tracks whether it got there.
[What the name means, in one line]
In 30 seconds
The point
- The problem
- Welfare schemes are announced at the top, but no one can easily see whether each eligible family actually receives them — not just whether they applied.
- What I built
- An Android app where NGO volunteers in villages enrol eligible people in schemes and track each application to the end, plus a web dashboard where leads see coverage roll up from village to region.
- My role
- Sole developer and product owner — requirements with the partner, database, app and dashboard.
- Where it stands
- In closed testing on Google Play, with the production database live under the Sau Foundation’s own account. A pilot of about 200 volunteers is planned [confirm dates].
- What it shows
- I can take a nonprofit’s real operational problem and turn it into working software, and keep its whole pilot on a free server plan — then measure it on a real phone and keep cutting.
My role
Sole developer & product owner
Built for
Sau Foundation, overseen by Maharashtra’s Assistant Commissioner of Social Welfare
Surfaces
Volunteer app · Web dashboard
Status
Closed testing on Google Play
[Screenshot: web dashboard]
[Screenshot: volunteer app]
The problem
Schemes are announced at the top. Do they reach the village?
Government welfare schemes are announced at the top, but whether they actually percolate down to each eligible household is hard to see. Gaav Tithe Sau gives that question an answer: volunteers on the ground record who is eligible for which scheme and move each application through an 11-stage pipeline until it succeeds or closes, and leads see the picture roll up from village to taluka, district and region.
[How you got involved, and who you’re working with — 2–3 sentences.]
Who it’s for
Built for the Sau Foundation
The Sau Foundation is an NGO working across Maharashtra’s villages, under the oversight of the state’s Assistant Commissioner of Social Welfare. Its volunteers help people from marginalised communities get the government welfare schemes they’re eligible for — and follow each case until the benefit actually arrives.
[About the foundation in your words: when it started, who leads it, where it works, and how you came to build this for them.]
The guiding rule: measure the worker’s action, not the beneficiary’s identity.
The people it serves
Eligible families in the villages
They never touch the app. It tracks the work done for them, and keeps as little about them as possible.
Phone app
Village volunteers
Enrol people in schemes and move each application forward, from first contact to the benefit arriving.
Phone + dashboard
Taluka, district and region leads
Watch progress across their area and spot where cases stall. Read-only, and totals only.
Dashboard
Foundation admins
Create accounts, assign volunteers to villages, add schemes and export reports.
What I built
A field app and a dashboard, sharing one database
Volunteer app · Flutter
For village volunteers (leads get read-only views)
- Add beneficiaries — Aadhaar is hashed on the phone and never stored
- Search the village’s beneficiaries, cache-first
- Move each enrollment through its status pipeline
- Works offline in read-only mode, in English and Marathi
Web dashboard · React + TypeScript
For taluka, district and region leads, and admins
- Coverage and stage-by-stage timing across hundreds of villages, from pre-computed totals
- Leads see totals for their area only, never individual people’s records
- Admins create accounts, assign areas and add schemes; leads and admins can export CSV reports
- One Supabase database behind both, secured by row-level rules
Design decisions
Every limit became a design decision
Every one of these started as a real limit and ended as a design decision.
-
Constraint
Running on a free server plan, where data transfer is the scarce resource
Decision
An offline-first app with a local database on the phone. Each volunteer downloads only the records they actually open, never the whole village.
-
Constraint
The commissioner’s office asked that volunteers never be able to burn through that bandwidth
Decision
No “refresh everything” anywhere. Pull-to-refresh re-checks only what’s on screen, so no amount of tapping can get expensive.
-
Constraint
Patchy connectivity in the field
Decision
Offline mode is read-only, with a bilingual “may be out of date” banner. Writes are disabled, not queued, so nothing can conflict later.
-
Constraint
Beneficiaries’ Aadhaar numbers are sensitive, and Indian rules restrict storing them
Decision
The phone hashes the Aadhaar number and clears it before anything is sent. The database keeps only nine fields per person — no phone numbers or addresses.
-
Constraint
Real people’s welfare records — mistakes aren’t acceptable
Decision
Separate test and production databases. Every change is a numbered migration, tried on test first; production started with no placeholder data. 80+ design decisions are written up in a log.
Reach
Who it serves
[#]
villages covered
[#]
volunteers onboarded (pilot plans for ~200)
[#]
scheme enrollments tracked
Reflection
What I learned
[2–3 sentences in your own words — e.g. what it’s like to build for a government office, or how designing for volunteers with limited connectivity changed how you think about software.]
App
Flutter, drift (SQLite)
Backend
Supabase (Postgres 17)
Web
React + TypeScript, Cloudflare Pages