← Back to Projects
Full-StackShipped

Penn Plates

Campus dining social app from Penn SPARK: auth, profiles, and a small student loop that actually shipped.

SPARK project with a real deadline. We built Penn Plates on Next.js and Supabase so students could coordinate around dining without a bloated feature list. Auth and RLS had to be right. Scope cuts hurt, but they are why we had a demo instead of half-finished screens.

Engineering highlights

  • Supabase auth and RLS for student profiles
  • Cut features to protect one usable dining loop
  • Demo-ready under the SPARK timeline
Date
2026
Focus
Product
Build stage
Demo-ready build completed
Disciplines
Product · Auth & Data
fullstackproductstudent-build
Demo
Full write-up below. The hero is the short version. This is the build story: what I designed, what broke, and why I made the calls I did.

Motivation

Why I started this

What pulled me in, and what I wanted to get better at.

Why I built it

SPARK project with a clock. Dining coordination for students, not a feature museum.

What interested me

Auth and RLS had to work. Everything else had to survive cuts.

What I wanted to learn

We shipped a smaller product that demoed instead of a larger one that did not.

System Overview

How the system fits together

Penn Plates: Next.js + Supabase campus dining app with auth and a small student interaction loop.

01

Auth/profile

Supabase-backed identity with RLS.

02

Social dining flows

Lightweight coordination features for students.

Data flow

Client actions → Supabase under RLS → shared dining state.

Engineering Breakdown

Broken down by discipline

Each block covers the goal, the design, what broke, what changed, and what shipped.

01Product Systems

Product Systems

Goal

Ship a usable student product on time.

Design

Next.js + Supabase with RLS-grounded profiles and a deliberately small interaction set.

Challenges

  • Ambition vs timeline.
  • Social features sprawl without a crisp loop.

Iterations

  • Scope cuts
  • Auth/profile hardening
  • Demo-ready polish

Final implementation

Demo-ready SPARK build with practical student flows.

Product demo

Student-facing dining coordination flow.

Key Design Decisions

Calls I actually made

What else was on the table, what I picked, and why it still made sense once the hardware was real.

01

Cut features to protect the core loop

The problem

What ships before demo day?

Alternatives considered

  • Wide feature set
  • Narrow usable loop

Tradeoffs

Wide looks impressive and breaks; narrow ships.

Why I chose this

Protect auth + core social dining loop.

Evolution

How it got here

Bench bring-up, CAD fits, soldering, and the demos in between. Not just the final photo.

  1. Build

    SPARK sprint

    Team execution to demo.

    No media for this milestone yet.

Results & Validation

What held up

What worked in the end, what I can show for it, and where it's still limited.

Demo-ready product

Demo video

Auth-backed student dining app completed under SPARK constraints.

Limitations

  • Campus-specific scope; not a consumer-scale launch.

Reflection

Looking back

What surprised me, what I'd redo, and questions I'm still chewing on.

What surprised me

  • Scope control was the real systems problem.

What I would redesign

  • Earlier user tests on the core loop.

Future improvements

  • Richer coordination only after retention evidence.

Questions that emerged

  • How do student teams practice saying no?