Free for the pilot — and ready to grow.

What I did

Opening the app makes one request: the volunteer’s profile, assignments, any scheme changes and census figures. There is no village-wide download. Records come down only when a volunteer opens something that needs them.

Why it works

Village-wide sync costs V × (V − 1) × D: every volunteer pays for every colleague’s work. At 10 volunteers that is ~90 MB a month for one village; at 20, ~380 MB. Tying downloads to use keeps it linear: ~0.5 MB and ~1 MB.

Why it fits GTS

A volunteer handles a roughly fixed number of people each month, however big the village gets. So their downloads track their own work, not everyone else’s.

What I did

An offline-first layer built on drift (SQLite). It stores only the columns screens actually show — about 120 bytes a record — and is capped at a few thousand rows so it can’t fill a cheap phone.

Why it works

Reading from the phone costs no egress. The server only has to answer “has anything changed?”, which is far smaller than “send me everything”.

Why it fits GTS

Offline is read-only, with a bilingual “may be out of date” banner. Writes are disabled, not queued, so there are no conflicting offline edits to untangle — volunteers simply retry when they’re back online.

What I did

A save goes to the server first. Once it’s confirmed, the phone caches the row with the timestamp the server sent back, and the screen updates from that cache — no follow-up download.

Why it works

Supabase bills data going out, not data coming in. Measured on the phone: after adding a beneficiary, the home screen showed the new record with zero extra requests.

Why it fits GTS

Most of what a volunteer looks at later is their own work — and it’s already on their phone.

What I did

For the records on screen, the phone sends one list of (record ID, last-updated) pairs, and the server returns only rows that are newer. It started as two checks, one per table; after measuring, I merged them into one request.

Why it works

Re-opening a cached 25-row list went from 3.6 kB to 0.9 kB, measured. When nothing has changed, the reply body is 40 bytes.

Why it fits GTS

Every timestamp the phone sends came from the server, never the phone’s own clock — a phone running fast could otherwise hide a colleague’s edit. So a matching timestamp means the copy is exactly what the server holds, and because an enrollment is usually worked by one volunteer, it was often written by this phone. “Nothing changed” is the normal answer.

What I did

Pulling down to refresh re-runs the freshness check for the rows on screen. There is no way anywhere in the app to download a whole village.

Why it works

Measured: a refresh on a list used to re-download all 25 rows (3.5 kB). It now costs about 1 kB, nearly all of it unavoidable request overhead.

Why it fits GTS

The commissioner’s office asked that volunteers never be given a way to burn through the budget. Refresh still feels responsive — it just can’t be expensive.

What I did

A nightly job on the server flags enrollments that have stalled. Instead of downloading those flags, the app recalculates them from data it already holds.

Why it works

The flag follows a fixed rule on two fields — current stage and last update — so the phone reaches the same answer without asking.

Why it fits GTS

Otherwise the nightly job would change many rows at once, and every phone would re-download them the next morning just to learn something it could work out itself.

What I did

I built an on-screen meter into the app that counts every byte and request by action, then logged sessions on a Samsung phone before and after every change.

Why it works

My design assumed ~250 bytes of overhead per request. The phone showed ~900: the app was speaking HTTP/1.1, so every response repeated its full headers. About 90% of an app open was headers, not data.

Why it fits GTS

That finding redirected the work. Since most responses here are tiny status updates, the cost worth cutting was the number of requests, not their size.

What I did

I combined separate server calls into single requests for the five most common actions — for example, one launch request instead of three, and one call to add an enrollment instead of a duplicate check plus two inserts.

Why it works

Measured: opening the app went from 6 requests and 7.7 kB to 2 requests and 2.0 kB. Adding an enrollment went from 3–4 requests to 1; opening a record from 3 to 1.

Why it fits GTS

The launch requests used to fire all at once, so each paid its own copy of a Cloudflare cookie. One request pays it once.

What I did

Switched the Android app’s networking to Cronet with HTTP/2, and added a cookie jar so Cloudflare’s bot-check cookie isn’t re-issued on every response.

Why it works

HTTP/2 compresses headers the connection has already carried: warm responses dropped from ~640 B of headers to 71–100 B. Without the jar, a ~320-byte cookie arrived with every response.

Why it fits GTS

Because this app’s responses are so small, headers were most of the bill — so the saving lands exactly where the app spends.

What I did

The app stores the scheme list and remembers the newest update time it has seen. Each launch asks only for schemes changed since then, inside the single launch request.

Why it works

Most launches get nothing back. When something does change, only those rows come down.

Why it fits GTS

The placeholder schemes were due to be replaced with real ones. A cache that only fetched new rows would have kept showing old names; tracking update times also catches renames and retired schemes.

What I did

Search shows matches from the phone immediately, then asks the server in one request. The server leaves out any result the phone already has, and sends back only the new or changed ones.

Why it works

Search is the most frequent network action. Volunteers mostly look up people they’ve already worked with, so most results cost nothing.

Why it fits GTS

Search covers the whole village, not just the volunteer’s own records, because a beneficiary may approach any Sau Foundation volunteer — who then needs to find their record.

What I did

Portal reference numbers, full status history and the latest note are never stored on the phone. They load in one request when a record opens, and are dropped when it closes.

Why it works

Lists and sync carry only the few fields every screen needs, so downloads and the phone’s database both stay small.

Why it fits GTS

The app targets phones with as little as 2 GB of memory. Keeping the local copy lean matters for the device as much as for the server.

What I did

Lists load 25 rows at a time and request only the columns they display. Deeper pages continue from the last row seen (keyset pagination) rather than “skip the first N rows”.

Why it works

Fewer bytes per row and fewer rows per request. Keyset pages stay fast at any depth and don’t skip or repeat records when data shifts mid-scroll.

Why it fits GTS

Colleagues keep updating enrollments while someone scrolls. A stable cursor means nobody silently disappears from the list they’re working through.

What I did

Copied the village ID onto the enrollments table, added an automatic last-updated time to beneficiaries, and indexed both tables by (village, last-updated).

Why it works

“What changed in this village since time T?” no longer needs a join or a full scan. The database jumps straight to the answer, however large the tables grow.

Why it fits GTS

Without a last-updated time on beneficiaries, one volunteer’s edit would have been invisible to every other phone’s copy. The whole sync design depends on it.

What I did

At ~1,600 enrollments the dashboard reported 33 MB, which suggested a ceiling of ~20,000. I found ~29 MB was fixed system overhead, then built 100,000 enrollments in a scratch schema to measure the real cost.

Why it works

100,000 enrollments fit in about 258–330 MB of the 500 MB plan. Along the way I dropped five redundant indexes, one worth ~15 MB at that scale.

Why it fits GTS

Status history is the one table that grows with every update, so it’s where the storage budget really goes — and where I check first.

What I did

Summary tables keep coverage counts already calculated at village, taluka, district and region level. A trigger updates them in the same transaction as each status change; heavier statistics are rebuilt nightly.

Why it works

Without them, one district dashboard load could scan thousands of records. At full scale that was estimated at ~67 GB of egress a month — more than 13 times the free allowance.

Why it fits GTS

Leads are allowed to see totals only, never individual people’s records — so pre-computed counts are exactly what they need.

What I did

Each beneficiary record holds just nine fields. The Aadhaar number is hashed on the phone and cleared before anything is sent; only the hash is kept, for spotting duplicates.

Why it works

Less data means less storage — and, more importantly, less that could ever leak.

Why it fits GTS

The goal is tracking whether schemes reach people, not building a registry of them. Aadhaar rules and India’s data-protection law make collecting the minimum the right default.