Project D — Community Event Pre/Post Survey — Build Tools That Save You Hours

Part 1 · The case

Dr Farah runs a one-day community health talk at a local mosque hall. Eighty people show up. She wants to answer one honest question at the end of the day: did this talk actually change what people know and feel?

The classic way to answer that is a pre and post survey. Same questions asked twice — once before the talk, once after — and then compare. The problem is never the questions. It's the plumbing: printed forms get lost, WhatsApp replies are chaotic, and typing the data into Excel at 11pm is where most projects quietly die.

What Dr Farah wants is boring: a QR code on a poster, a phone- friendly form, and a dashboard she can open the same night to show her team the "before vs after" numbers. That's what this project builds — and we'll build it two different ways so you can pick.

Part 2 · What you're building

A Community Event Pre/Post Survey. Two short forms with the same questions, one comparison dashboard, and a clear "before vs after" story at the end of the day.

Pre survey — a short form at the door. Same core questions you'll ask again at the end.
Post survey — the same questions, plus a couple of "what did you take away?" items.
Comparison dashboard — one page for the organiser: how many replied, average scores before vs after, top take-aways.
No accounts for respondents — people at a community event will not sign up. A short link (or QR code) is enough.

Part 3 · Who uses it & how

Respondents (everyone at the event)

Scan a QR code on the poster, fill a 60-second form, hit submit. No sign-in, no accounts. The post link is a different QR on a different poster shown at the end.

The organiser (Dr Farah & her team)

Opens a private dashboard. Sees response counts, average scores side by side, and a simple bar chart per question: blue bar = before, coral bar = after. Nothing else.

Part 4 · The survey (pre vs post)

The core rule: ask the same questions before and after. Otherwise "before vs after" is nonsense.

Shared block (asked twice) — five short "how much do you agree" statements on a 1–5 scale (e.g. "I know the warning signs of diabetes").
Pre only — one demographic block (age range, whether they've attended a similar talk before).
Post only — two open questions ("one thing you'll do differently this week", "one topic you still want covered") and a 1–5 satisfaction score.
An event code — a short string like KKM-2026-04 stamped on every response, so the same tools can host many events over time.

Anonymous vs matched

Simplest and safest: anonymous. You compare group averages before and after, not individual pre→post pairs. If you truly need matched pairs, ask each respondent to make up a short private code (e.g. their mother's initials + birthday day) and repeat it on the post form. Never collect real names or IC numbers for a community talk.

Part 5 · Two ways to build this

Same product, two very different tool choices. Pick the one that matches how much control you want and how much your team already knows.

Variant A · Full-stack in Lovable Cloud

Two public form pages (/pre and /post), one private admin dashboard, one database with two tables. Everything lives inside the app you built. Best when you want a branded, polished experience and full control over the questions.

Variant B · Google Forms + Google Sheets

Two Google Forms collect responses into two tabs of one Google Sheet. The sheet is published to the web as CSV. Lovable is only the dashboard — it fetches those CSV links and draws the charts. Best when your team already lives in Google Workspace.

Variant A — every piece is inside your Lovable app.

Variant B — Google collects, Lovable only reads and displays.

Part 6 · Variant A · The Power Prompt (Lovable Cloud)

A few plain-language notes before the prompt:

Two public pages — /pre and /post. Anyone with the link can submit. No sign-in.
One private page — /admin. Sign-in required. Only the organiser account can read totals. Every row in the database is stamped with an event code; the admin filters by it.
Two tables — pre_responses and post_responses. Same shared columns, plus the pre-only or post-only columns.
The rule that keeps it safe — the public forms are allowed to write a new row (with the event code) but never read anyone's rows back. Only the signed-in admin can read.

Goal — Build a community event pre/post survey tool. Two public forms and one private dashboard. The dashboard shows before-vs-after averages per question and total response counts, for one event code at a time.
Roles — Two audiences. Respondents have no account and see only the form for the event they were invited to. Admin signs in and sees the dashboard for the events they own.
Layout — Three routes. /pre?event=CODE shows the pre-survey form with the event code prefilled and read-only. /post?event=CODE shows the post-survey form the same way. /admin shows a dropdown of the admin's events, response counts, and a bar chart per shared question (pre average vs post average).
Data — Table events (code, title, owner). Table pre_responses and post_responses each have: id, event_code, submitted_at, and one column per survey question. Rules: anyone can insert into the two response tables (if the event_code exists); only the event owner can read them. Only the event owner can read or edit their events row.
Features — Email/password sign-in for admin (with forgot-password email). Admin creates an event and gets two shareable links (pre and post) that already include the event code. Dashboard filters by event code and shows: total pre responses, total post responses, and a bar chart per shared question. Empty states are polite ("No responses yet — share the pre link.").
Output — A short-link poster the admin can print with a QR code, and a live dashboard for the debrief.

Part 7 · Variant B · The Power Prompt (Google + Lovable)

In this variant, Lovable does not collect any data. It only reads two CSV links (one per Google Sheet tab) and draws the same dashboard. That means: no database, no sign-in for respondents, and the dashboard itself is a very small app.

Goal — Build a read-only dashboard that compares two Google Sheet CSVs — one pre-event survey, one post-event survey — and shows before-vs-after averages per shared question.
Inputs — Two "Publish to web" CSV URLs the admin pastes into a settings screen: PRE_CSV_URL and POST_CSV_URL. Also a plain-text list of the shared question column names (the questions asked on both forms). Store all three in a small settings table keyed to the signed-in admin.
Layout — Two routes. /settings for the admin to paste the two CSV URLs and the shared question names. /dashboard fetches both CSVs, parses them, and shows: total pre rows, total post rows, last-updated time, and a bar chart per shared question (pre average vs post average, 1–5 scale).
Auth — Only the admin signs in. Respondents never touch this app — they only interact with the Google Forms.
Behaviour — The dashboard refreshes when the admin opens it and has a "Reload" button. Google publishes CSVs with a short cache delay (a few minutes), so tell the admin the numbers are near-live, not instant.

Part 8 · Wiring the Google Sheet (Variant B)

This is the plumbing that trips most people. Do it once, and the dashboard reads live for the rest of the event.

1Create two Google Forms
One for pre, one for post. Same first five questions, in the same order, on both. Add the event code as a short answer question with a default value if the form settings allow it, or just tell people what to type.
2Send both forms into one Google Sheet
In each form, open Responses → Link to Sheets. Point them at the same spreadsheet. You'll get two tabs, usually named 'Form Responses 1' and 'Form Responses 2'. Rename them 'Pre' and 'Post' so you don't mix them up later.
3Publish each tab to the web as CSV
In the Google Sheet: File → Share → Publish to web. Pick the 'Pre' tab, format 'Comma-separated values (.csv)', click Publish. Copy the URL. Repeat for the 'Post' tab. These are the two links the Lovable dashboard will fetch.
4Paste both URLs into /settings
Open the Lovable dashboard at /settings while signed in as the admin, paste PRE_CSV_URL and POST_CSV_URL, save. Open /dashboard — the charts render from the sheet.
5Test with a fake submission
Submit one fake pre response and one fake post response through the Google Forms. Wait ~2 minutes (Google caches published sheets), hit 'Reload' on the dashboard. If the count goes up, the wiring is correct.

What 'Publish to web' means

Publishing a tab to the web makes only that tab readable as a CSV at a public URL. It does not expose the whole spreadsheet and it does not let anyone edit anything. Anyone with the URL can read the responses, so don't collect names, IC numbers, or emails in the pre/post questions.

Both variants share the same distribution playbook — a link, printed as a QR code, on the posters at the event.

Variant A — your two links are the Lovable app's own routes: https://yourapp/pre?event=KKM-2026-04 and https://yourapp/post?event=KKM-2026-04. Print each as a QR on its own A4 poster.
Variant B — Google Forms gives you a "Send" button → "link" tab → a shortened forms.gle URL. Use that for the QR code. Two QRs, two posters.
Turn a link into a QR — any free QR generator works. Paste the link, download the PNG, drop it onto an A4 with the event title and one instruction: "Scan to start."
Show the right QR at the right time — pre poster at the door before the talk, post poster on the wall after. Same event, two moments.

Part 10 · Which variant should you pick?

Pick Variant A (Lovable Cloud) when…

You want a branded look, custom questions, custom logic (e.g. skip a question based on an earlier answer), or a real product you can reuse across many events. You're comfortable with the app owning the data.

Pick Variant B (Google + Lovable) when…

Your team already builds forms in Google. You want the raw data in a familiar spreadsheet for later analysis. You want to ship the dashboard in an hour and don't need branded forms. You accept the CSV cache delay.

Part 11 · Strengths & trade-offs

Variant A · Lovable Cloud

Full control over the look, the questions, and the URL. Feels like a real product, not a form.
One event code system across many events over time — reusable.
Trade-off: you now own a database. Set up the rules carefully and don't collect data you don't need.

Variant B · Google Forms + Sheets

Fastest path to the first response. Google handles forms, storage, and email confirmations for free.
Data stays in a spreadsheet the whole team already knows.
Trade-off: the published CSV is public — anyone with the URL can read it. Never collect identifiers there.
Trade-off: Google caches published CSVs for a few minutes. Fine for a debrief; not instant real-time.

Part 12 · Sample survey questions

A starter set you can copy for a community health talk. Same five shared questions on a 1–5 agree scale, plus the pre-only and post-only extras.

Shared (pre & post) — 1 to 5, Strongly disagree → Strongly agree
Q1. I know the main warning signs of diabetes.
Q2. I know at least three small daily habits that reduce my risk.
Q3. I feel confident talking to a doctor about my results.
Q4. I know where to get a free health screening near me.
Q5. I feel motivated to change one thing this week.
Pre-only
Age range (under 25 / 25–39 / 40–59 / 60+).
Have you attended a similar talk before? (Yes / No)
Post-only
One thing you will do differently this week (short answer).
One topic you still want covered (short answer).
Overall, how useful was this talk? (1–5)

Part 13 · Extend it

Multi-event history — the admin picks any past event from a dropdown and re-opens its dashboard for a report.
Optional matched pairs — a short private code the respondent makes up, repeated on the post form, so you can look at movement per person without collecting real names.
Auto-generate the two QR posters — the admin creates the event and downloads two A4 PDFs, ready to print.
Export to CSV from the admin dashboard (Variant A) — one file per event, opened directly in Excel or Google Sheets.
A public 'thank you' page after submit with a link to the next event.

Next lesson — Project E

The last project is the strictest posture in the whole course: one signed-in user, one private log, nobody else ever sees the data. The Personal Study Tracker. Same toolkit as this one, opposite security rule.

PreviousProject C — Live Field Tally Next Project E — Personal Study Tracker

Project D — Community Event Pre/Post Survey