Now booking new projects - limited availability
Baraworks
All work
Community Web App2026ephesians428.org

GBC Help Board

A private help board for a Windsor church family - members ask for a hand, approved helpers offer, and the first to offer is matched, with the privacy rules enforced in the database rather than the interface.

ephesians428.org
GBC Help Board front page: 'Helping one another as a church family' above the helper and requester doors
Overview

Grace Bible Church had people willing to help and people who needed it, and a volunteer coordinating the two by hand in a spreadsheet. We built them a board. A member posts a request - yard work, moving, a ride, childcare, tech help - and every approved helper is emailed without being told who asked. The first helper to offer is matched atomically, and only those two people are introduced to each other. Nobody else ever learns who helped whom. The church office sees everything. The hard part was not the interface: it was making sure a bug in the interface could not leak anything, so the privacy rules live in Postgres as row-level security, a restricted view and locked-down SQL functions, verified by a scripted check covering twenty-three cases.

Outcomes
Portals: helper, requester, admin
3Portals: helper, requester, admin
Privacy cases verified by script
23Privacy cases verified by script
Request categories, rides to childcare
10Request categories, rides to childcare
Inside the build

What shipped, screen by screen

Privacy by construction

Helpers never see who asked

A helper browsing the board sees the task, the area and the contribution, and nothing that identifies the person. That is not a UI decision: helpers read a separate database view that has no requester column in it at all, behind row-level security that checks their account on every query. A mistake in the front end has nothing to leak.

  • Restricted Postgres view, no requester identity
  • Row-level security on every table
  • 23-case scripted check on the rules
Open requests board showing tasks, areas and contributions with no requester names
Matching

First to offer, and only then introduced

Offering to help runs through a single conditional update inside the database, so two people tapping at the same moment cannot both win and the loser is told immediately. The match introduces exactly two people to each other by email. If plans change the helper can step back, and the request returns to the board.

  • Atomic accept, no double-booking
  • Contact details revealed to the matched pair only
  • Step back reopens the request and re-notifies
A request detail page showing the task, the financial contribution and the offer-to-help button
Oversight

The office sees what nobody else can

Admins get the whole picture that the privacy rules deny everyone else: who asked, who offered, and every state change as an audit trail written by a database trigger. They invite helpers by email, grant and revoke access, and step in to unmatch, reopen or cancel a request. Seven transactional emails keep everyone informed without anyone needing to check the site.

  • Full activity trail from database triggers
  • Invite-only helper accounts, revocable
  • 7 notification emails across the lifecycle
Admin overview with request counts and a full activity feed naming who posted and who offered

Have a project in mind?

Tell us what you're building. We'll get back to you shortly with next steps - no obligation.