Hack4Impact · Paso Robles Food Co-op · 2025–2026
PRFC Connect
A communication and events platform used by a real community food co-op.
- Next.js 16
- TypeScript
- Prisma
- MySQL
- Docker Compose
- Vitest
- Playwright
402
members visible in the live dashboard
referrals were one lever; community participation was the larger system
The co-op's 500-member goal remained the anchor, but the product question broadened: instead of only helping members invite someone new, how could software help the co-op communicate with and engage the members it already had?
PRFC Connect became a real production platform for member groups, targeted outreach, events, RSVPs, referrals, and notification activity. The co-op's own portal remains the identity source and entry point rather than PRFC Connect duplicating all member data.
from a referral lever to a community platform
This is an evolution in product scope, not a claim that the software caused membership growth. The 402 / 500 dashboard is a point-in-time production snapshot of the co-op's stated goal.
- 01500-member goal
- 02referral-first tool
- 03community engagement question
- 04groups + messages + events + RSVPs + referrals
- 05PRFC Connect
a working surface for community operations
Role-aware dashboard
Members and administrators enter a home view shaped by their role, available groups, events, and recent activity.
Member groups
Organizers assemble contact groups so communication can target the right part of the co-op rather than the entire list.
Messages + notifications
Brevo powers group email, and the product tracks per-member notification activity. Twilio SMS and its safeguards are implemented, but SMS remains disabled in production because the nonprofit chose not to take on the recurring operating cost.
Events + RSVPs
Admins create events, invite members or groups, and see response activity alongside the wider outreach workflow.
Referrals
The earlier referral idea remains inside the broader product, now protected by the shared session and service architecture.
Portal handoff
The co-op's member portal validates identity and hands users into PRFC Connect without making this app the source of truth for member PII.
the production architecture in context
Next.js 16 + React 19
Provides server components, authenticated routes, and the member/admin product surfaces.
Actions → services → Prisma
Zod-validated server actions enforce auth before calling server-only domain services and the MySQL data layer.
Portal-backed identity
Member PII stays in the co-op portal; request-memoized lookups avoid turning PRFC Connect into a second identity database.
Protected stored PII
Referral and SMS fields stored locally use AES-256-GCM encryption plus HMAC blind indexes for lookup.
Brevo, Twilio, Redis, Blob
Brevo sends email. Twilio SMS is implemented but disabled for an operating-cost decision. Upstash handles rate limits, idempotency, and quotas, while Blob stores uploaded assets.
Docker Compose
The team-standard local workflow runs MySQL 8.0 and Adminer through Docker Compose. I used that environment during development, but did not author the Compose setup, and it is not the Vercel production deployment mechanism.
Vitest + Playwright
The repository has 689 Vitest tests across 59 files, plus browser flows that seed, wait for, and clean up their own data.
Built into the co-op’s real workflow
The strongest proof is not a deployment badge: the co-op’s own member site thanks Cal Poly and Hack4Impact and links directly into PRFC Connect.
The production screenshot shows 402 of 500 members and real upcoming events. It is a point-in-time view, so I do not extrapolate usage metrics from it.
Moving referrals onto session auth
I helped migrate the referral feature away from URL checksum authorization and into the app’s session-cookie pattern, including an ID-scoped API route, deletion behavior, input validation, and route tests.
Review caught an important distinction between any signed-in member and an administrator. That correction became one of my clearest lessons about authentication, authorization, and check ordering.
The first authenticated home
I built the original role-aware home view, with server-side group loading for members and admins, empty states, semantic card behavior, and Playwright coverage that seeded and cleaned up its own data.
The dashboard shown today was later expanded by the team; I use it here to show the current product while keeping the story of my work focused on the first version and its foundations.
When a group counted as a person
The event invitee picker displayed N+1 people because selected group IDs were being mixed with the actual member IDs expanded from those groups.
I fixed the data model behind the display instead of patching the number, then strengthened the test fixtures so they represented real group-to-member relationships.
the product areas I owned or changed
As one of two student tech leads, I contributed to product direction and technical planning while implementing three focused slices: the referral security migration, the first authenticated home, and a data-model fix in event invitees.
The current dashboard contains later team work too. I describe the whole platform in team language, then keep my technical story anchored to the merged changes I can trace directly.
- Migrated referrals from URL-checksum authorization to the shared session pattern and added authenticated PATCH/DELETE routes.
- Built the first role-aware authenticated home with server-side group loading, empty states, semantic card behavior, and Playwright coverage.
- Fixed invitee overcounting by separating selected group IDs from the deduplicated member IDs expanded from those groups.
- Strengthened fixtures so tests represented real group-to-member relationships instead of convenient flat IDs.
- Co-designed auth/data/layering decisions; the other tech lead authored most of the architecture documentation and implementation.
planning, review, demos, and a real nonprofit client
The 12-person team worked through an eight-sprint plan with bi-weekly sprint, project, and design-review meetings. Tech leads translated product needs into implementable slices, developers and designers coordinated handoffs, and pull requests moved through review and testing before demos.
One review changed my authorization code from a broad signed-in check to the correct admin boundary. That feedback is part of the case study because it shows how the team made the product safer, not because every PR arrived perfect.
plan
Review the backlog, client needs, dependencies, and design readiness.
slice
Turn a product capability into developer-sized tickets and test expectations.
review
Use PR feedback to catch auth, data-shape, accessibility, and integration issues.
demo + adjust
Show working increments and revise the next sprint around what the nonprofit needs.
a few more pages from the process
results, with context
members shown
Real production data visible in the supplied dashboard capture.
tests
Vitest tests across 59 files at the time of the repository review.
nonprofit adoption
The co-op’s own member portal links directly into the tool.
Working on a system with real member data made small design choices feel consequential. The review that tightened my authorization logic is something I would rather remember clearly than edit out of the story.