ResQPlate: Surplus Food Redistribution Platform
A capstone-scale team project: businesses list surplus food, verified through an approval workflow, and it's discovered by nearby seekers through geo-aware search. I owned the backend auth system, the GCP deployment pipeline, secrets management, and search indexing.
- Role
- Team project
- Timeline
- Jun - Jul 2026
- Impact
- A full-stack platform connecting restaurants with surplus food to people who need it. I led backend, deployment, and CI/CD for a five-person team.
Attribution: Built with a five-person team over six weeks. My scope: authentication, CI/CD and deployment pipelines, GCP infrastructure and secrets management, search indexing, and backend testing, not the full application.
Private team repository, not linked publicly.
restaurant listing verification workflow
Concepts demonstrated
- Authentication & authorization
- CI/CD & deployment
- Cloud infrastructure
- Relational schema design
Highlights
- Built the deploy pipeline: GitHub Actions workflows SSH/SCP a build to a GCP Compute VM, pull secrets (DB URL, auth secret, API keys) from GCP Secret Manager at deploy time rather than baking them into the image, and run the service under PM2.
- Made the deploy self-verifying: it polls the health endpoint with backoff before declaring success, and dumps recent process logs on failure instead of failing silently.
- Owned authentication end-to-end (signup/login/session middleware) and debugged a cross-origin cookie issue through a Cloudflare Workers proxy in front of the API, tracing it down to how the proxy handled credentialed requests.
- Designed the search/discovery path: Algolia indexing sequenced deliberately after each deploy's health check passes, so search results never point at a backend that isn't actually up yet.
Problem
Restaurants generate surplus food that would otherwise go to waste, while nearby individuals and community organizations could use it. The platform needed role-based accounts (food-seekers, businesses, admins), a verification workflow so listings are trustworthy, and location-aware discovery, plus the operational scaffolding to actually run and deploy it as a team of five.
Engineering approach
- Split ownership along real seams: I took backend infrastructure, auth, deployment, and search, while teammates built out the listings, reservations, and frontend surfaces.
- Started from a Dockerized local Postgres + npm-workspaces monorepo so backend, frontend, and shared types could evolve together without drifting.
- Treated deployment as a first-class engineering problem, not an afterthought bolted on at the end. CI workflows and a working deploy pipeline existed early, not just before the deadline.
Architecture
- Express 5 + Drizzle ORM over PostgreSQL, with a normalized schema: profiles → restaurant profiles (with a PENDING/APPROVED/REJECTED/SUSPENDED verification state machine) → food listings → reservations, plus a many-to-many allergen mapping.
- better-auth for session-based authentication, with CORS and cookie handling tuned for a Cloudflare Workers proxy sitting in front of the API in production.
- Algolia for geo/faceted search over listings, with haversine distance calculations for 'near me' queries, backed by a Google Places-driven address autocomplete on signup.
- GitHub Actions workflows for backend deploy, frontend deploy, and database migrations, each pulling secrets from GCP Secret Manager at run time.
Technical challenges
- The hardest bug was a cross-origin, credentialed cookie failure that only showed up once the API sat behind a Cloudflare Workers proxy. The browser, the proxy, and the API all needed to agree on cookie domain, SameSite, and CORS headers simultaneously, and getting one wrong looked identical to getting all of them wrong from the client side.
- Coordinating deploy ordering across two services and a search index required making the ordering explicit in the workflow rather than trusting timing: the backend has to be healthy before the frontend deploy points at it, and the index shouldn't be rebuilt against a backend that's mid-restart.
Decisions
- Pulled secrets from GCP Secret Manager at deploy time instead of storing them in CI environment variables, so rotating a key doesn't require touching the pipeline config.
- Used PM2 for process management on a single VM rather than reaching for Kubernetes. The team's timeline and scale didn't justify the operational overhead, and a health-check-gated PM2 restart covers the actual failure modes that mattered.
- Wrote repository/service-level backend tests with Node's native test runner plus c8 coverage instead of pulling in a separate test framework, keeping the dependency surface smaller.
Result
A deployed, working platform with a real CI/CD pipeline, a properly normalized schema, and a deploy process that fails loudly and informatively instead of silently, built and shipped by a five-person team in six weeks.
Learnings
- Treating deployment as first-class from week one meant the team never had a 'how do we even ship this' scramble before the deadline. Building the pipeline early paid for itself repeatedly.
- The deploy pipeline SSHes into a single VM. The honest next step before this handled real traffic would be moving off a single instance, so a bad deploy or a crashed process doesn't take the whole service down.