Problem

Silent auctions look simple until you work through the trust model and event logistics. Bidders need a fast, phone-friendly flow. Organizers need visibility and control. Donors need a separate way to manage contributed items. The system also has to protect bidder privacy and enforce auction rules on the server.

Context / users

I built this as a real operations tool for a school fundraiser. The job was to make public bidding feel simple for families while still giving organizers the controls they actually needed.

Solution

I structured the app around trust boundaries. Public catalog and bidding surfaces stay fast and interactive, while sensitive operations run through server-side routes backed by Supabase and validated before any state change is accepted.

• Guided bidder onboarding with email verification and alias/avatar creation
• Alias-based bidding to preserve privacy during the live auction
• Mobile-friendly catalog with category filtering and per-item detail pages
• Realtime bidding updates powered by Supabase
• Bidder dashboard for tracking bids and managing notification preferences
• Leaderboard views for hot items, bidding wars, popular items, and top earners
• Donation pledges alongside item bidding
• Donor portal for registered donors to manage donated items
• Admin dashboard for item management, auction timing, QR access, donation review, and closeout
• Automated winner and admin email workflows

Architecture

The project uses Next.js App Router for the application shell, Supabase for PostgreSQL and realtime updates, and Resend for transactional email. Public pages, donor flows, and admin routes are separated. Anon Supabase access handles catalog and realtime behavior, while service-role access stays in API routes and protected server-side operations.

Engineering Details

• • Next.js 16 + React 19 gave the project a modern App Router foundation with a clean separation between public pages and protected routes
• • Supabase fit the problem well because the project needed both relational auction data and realtime bid updates
• • Resend handled transactional email flows for verification, outbid, winner, and admin notifications
• • Zod-based validation and server-side bid enforcement keep auction rules out of the UI layer
• • The architecture distinguishes anon client access from service-role server access, which is the right trust boundary for a public bidding system
• • Admin and vendor access are not treated as the same problem: admin uses Basic Auth on protected routes, while vendor flows use HttpOnly session cookies
• • CSRF protection and rate limiting were added around state-changing flows like bidding, donations, alias creation, and vendor item actions
• • The demo-mode path is an architectural feature, not just a UI switch: it isolates public showcase behavior from real-event data and email side effects

Outcome

• Built a real event operations platform instead of a one-off fundraiser microsite
• Created a smoother auction experience for bidders while giving organizers structured control over items, timing, closeout, and communications
• Protected sensitive workflows by enforcing auction rules and auth boundaries server-side instead of trusting the browser
• Added a separate donor workflow and donation support, making the platform broader than a simple bidding app
• Turned the project into a strong portfolio-grade reference for full-stack architecture, realtime UX, security hardening, and operational tooling

Tradeoffs / Limits

• • The repo includes targeted unit tests for bid rules and vendor sessions, but this is not yet a heavily test-saturated codebase
• • The documented rate limiting is in-memory, which is reasonable for this scale but not the final form for multi-instance production traffic
• • Like many practical apps, some user-facing pages remain interactive and client-heavy because responsiveness matters during event use
• • The strength of the project is not theoretical perfection. It is that the risky parts of the workflow were identified and deliberately hardened

Why It Matters

It demonstrates product thinking, trust-aware backend design, realtime data flow, role-based access patterns, and the discipline to build the parts an organizer actually depends on.