Project C — Live Field Tally

Part 1 · The case

Zara helps run a weekend food-relief drive in a large housing area. On distribution day, seven volunteers stand at seven different tables, each handing out one type of aid — rice, cooking oil, baby formula, hygiene packs, and so on. Cars queue up, families collect what they need, and volunteers try to keep count on paper.

By 4pm the tally sheets never agree. One table swears they handed out 180 packs; the sign-in list at the gate says 210 families came through. Nobody knows the real number until Monday, after somebody sits down and re-adds everything in a spreadsheet. Meanwhile Zara — coordinating on WhatsApp — has no idea whether to send more supplies to table 3 or pull them from table 5.

What she wants: a big number on her phone that goes up the moment any volunteer taps a button on their phone — no refresh, no waiting. That's what this project builds.

Part 2 · What you're building

A Live Field Tally. One event, many volunteers, one shared live number.

Volunteers open the app on their phone, pick which station they're at (e.g. "Table 3 — Rice"), and tap one big "+1" button each time a family collects aid. Zara — and every other volunteer — sees a live dashboard where the total, and each station's number, tick up in real time. No refresh. No spreadsheet at 10pm.

Two important terms up front:

• Real time — a change made on one device shows up on every other device within a second or so, without anyone reloading the page. The app "pushes" the update instead of waiting to be asked.
• Station — one of the tables in the field (Rice, Oil, Baby Formula…). Each station is just a label the volunteer picks once when they sign in for the shift.

Part 3 · Who uses it & how

Part 4 · The Power Prompt to start

A few plain-language notes before reading the prompt:

• Event — one distribution day. The whole app is scoped to one active event at a time. Next week's drive is a new event.
• One row per tap — every "+1" saves a small record in the database (see Part 5) rather than adding to a single counter. This is important: it means we can never lose count, we can undo a tap safely, and we can slice the numbers by station or by volunteer later.
• Live subscription — a modern trick where the database can tell every open dashboard, the instant a new row lands, "hey, refresh yourself". No polling, no refresh button.
• Offline-safe — the field has patchy signal. If a volunteer taps "+1" while the phone is offline, the tap is remembered on the phone and sent up the moment the signal comes back.

Goal — Build a real-time tally for a one-day field event. Many volunteers on phones, one shared live number on a coordinator's dashboard.

Roles — Two kinds of people. Volunteers sign in with a short 6-character event code. Coordinators sign in with email/password + Google. Only coordinators can open a new event, create stations, and see the dashboard.

Layout — Volunteers see one page: a big "+1" button in the middle, the station name at the top, an "undo last" button at the bottom. Coordinators see a dashboard: one giant total that ticks up live, a row of per-station counters underneath, and a small "share view-only link" button.

Features — Every "+1" saves one row tagged with the event, the station, the volunteer, and the exact time. The dashboard uses a live subscription so numbers update within a second without a refresh. If a phone is offline when a tap happens, the tap is stored locally and sent when the signal comes back. Only the coordinator who created the event can end it or see the full breakdown by volunteer.

Output — During the event: a live board. After the event: one summary page with the totals per station, per volunteer, and a downloadable spreadsheet (CSV) of every tap.

Part 5 · Data & flow

Four small tables

Same idea as the past two lessons: a "table" is just a named list of rows. This project needs four of them, each tiny.

• events — one row per distribution day. Columns: id, name (e.g. "Ramadan drive · 15 March"), the coordinator's account id, the short 6-character volunteer code, and a status (open / closed).
• stations — one row per table at the event. Columns: id, event id, label (e.g. "Table 3 — Rice"), and a display order.
• volunteers — one row per person who signed in with the event code, so the app can name and undo their taps. Columns: id, event id, display name, and the time they joined.
• taps — the heart of the app. One row per "+1". Columns: id, event id, station id, volunteer id, and the exact time (down to the millisecond). The live total is just count the rows in this table for this event.

The security rules

This one is more interesting than the past two projects because two different kinds of people can write to the database — and we don't want them stepping on each other.

• Reading the live number — anyone with the volunteer code (or a share link the coordinator hands out) can see the running total and the per-station numbers for that one event. No other events. No personal names on the public view.
• Writing a tap — only signed-in volunteers of that event may add a row, and the row must be tagged with their own volunteer id and a station that belongs to the same event. The database refuses anything else.
• Undoing a tap — a volunteer can only undo their own last tap, and only within a short window (say 60 seconds). Anything older belongs to the record.
• Creating events / stations / ending the event — only the coordinator who owns the event. Nobody else, ever.

Part 6 · What matters for this project

From the five foundations in Lesson 1, this project leans on:

1. 1Real-time database (the star)

   The whole product is 'one number, live, everywhere'. That only works if the database can push updates to every open dashboard the moment a new row lands. This is a built-in feature — you turn it on for the taps table and every subscribed screen updates within a second.

2. 2Auth (two flavours)

   Coordinators sign in with email/password + Google — they're the owners. Volunteers sign in with a short 6-character event code so they don't need an email account just to hand out rice. Both flavours give them an account id the database can use for the security rules.

3. 3Security

   The tricky part. Volunteers can add taps but never edit past ones. Coordinators can see everything for their event, nobody else's. The public share link can read the running total but never the list of volunteer names. Every rule is enforced by the database itself, not by hoping the app is nice.

4. 4Cloud (the always-on computer)

   Small role here. One background job at midnight closes yesterday's events and computes the summary numbers so tomorrow's dashboard doesn't have to recount every tap from scratch.

5. 5AI

   Not needed for the core. Everyone knows what a '+1' means. AI could later summarise the day in words for a WhatsApp update, but it isn't part of Project C.

Part 7 · Strengths ✅

• The coordinator sees the truth in real time — no more 'wait until Monday' spreadsheets.
• Any volunteer can join in 10 seconds using a short code. No email accounts, no app store, no training.
• Because every tap is its own row, the app can't lose count when many phones tap at the same instant.
• The same data supports the live view and the after-event summary. No extra reporting step, no re-entry.
• Small and cheap. A whole event fits in a few thousand tiny rows. The database and hosting cost pennies per event.

Part 8 · Weaknesses & trade-offs ⚠️

• Trust model. A volunteer can spam the '+1' button and inflate the count. Fine for a friendly community drive; not fine if the number is tied to money. The lesson here is to match the tool to the stakes.
• No signal, no live view. Volunteers can still tap offline and their taps sync later, but the coordinator's live dashboard needs a working connection to update.
• Coordinator can only run one event at a time on a given phone (by design — 'the event' is the current context). Two overlapping events means two coordinators.
• Real-time features cost slightly more than plain reads/writes. For hundreds of taps a minute this is nothing; for a whole city of events, size the plan up.
• The '+1' interface is fast but flat. If a station really needs to count 'rice · 5kg vs 10kg', that's a bigger UI change than it looks — plan it before shipping.

Part 9 · Dummy files to test with

Two small CSVs so you can seed a fake event on day one instead of typing station names and volunteer names by hand. Both are made up. Import them from the coordinator screen when you're wiring up "Create event".

Part 10 · Extend it

• Add categories per station (5kg / 10kg / kids), so '+1' becomes three buttons and the summary breaks down by size.
• Add a QR code at each station that opens the app already pointed at that station — one less tap for every volunteer.
• Add a simple 'families served' page for the public: a big live number embedded on the NGO's website while the drive is running.
• Add an AI end-of-day summary that reads the numbers and writes one WhatsApp-ready paragraph for the group chat.
• Recurring events: turn one drive into a monthly programme, with month-over-month numbers on a longer dashboard.