Where they started

The coalition's previous site was a 4-megabyte WordPress build with a hero video, a stock-photo slider, and a petition form three scrolls down. On urban 4G it looked slick. On the phone of a rural volunteer over 2G it took forty-three seconds to render — long enough that most volunteers gave up.

The petition was the whole point of the site, and the people who most needed to sign it couldn't.

What we built

  • An 87 KB static site. HTML, one CSS file, one lightweight JS file for the petition form. No video. No slider. No third-party analytics tracking pixels. Above-the-fold content rendered in 2.1 seconds on the same 2G test phone.
  • An offline fallback. A service worker cached the shell so volunteers could load the site once, then walk into a village with no connection and still open the petition form. The signatures synced when they got back to reception.
  • A translation workflow. Content in a flat Markdown structure, one file per language. Eight volunteers were trained to publish new translations themselves without touching code. They shipped 6 languages in the first three weeks.
  • Petition tooling with no vendor lock-in. Signatures stored in the coalition's own Airtable, not on a proprietary petition platform. If they wanted to move the campaign to a different tool tomorrow, they could.

What it moved

By end of campaign: 87 KB total page weight. 312,000 petition signatures. 3 countries actively organising around the site. 6 languages live, all translated by coalition volunteers. 0 vendor lock-in.
"It loaded on my mother's phone in the village. That had never happened before."

Beyond the signatures, the useful outcome was that the coalition could now report to funders which regions the petition had actually reached, not just where the impressions had landed. Half a million impressions in Delhi was less interesting than 12,000 signatures in one Uttar Pradesh district — and now they could show that.

What we'd do differently

We under-invested in the volunteer training programme in week one — we assumed the CMS was intuitive enough that a quick call would suffice. It wasn't. A four-hour in-person workshop in week two paid for itself in six weeks of avoided support requests. Front-load the training for the people who'll own the site after you leave.