Spider-Man hanging upside down
FIG. 01

Ticket Resale Platform

A full-stack marketplace where fans resell event tickets safely — ML fraud scoring, real-time inventory sync, and QR-based verification, split across three independently deployed services.

ROLE
Solo Developer
TIMELINE
8 weeks
TYPE
Full-Stack Web App
STATUS
Live
3
SERVICES DEPLOYED
2
DATABASES
8
WEEK BUILD
0→1
SOLO, START TO PROD

Live Preview

The actual deployed app — click to launch it inline.

Screenshot of Ticket Resale Platform
TICKET RESALE PLATFORM
ticket-resale-phi.vercel.app
OPEN ↗
ticket-resale-phi.vercel.app
LOADING PREVIEW...

Case File

Three angles on the same build — click through.

// WHY THIS NEEDED BUILDING

Ticket resale runs almost entirely on trust with nothing behind it. A buyer sees a listing, pays, and hopes the ticket is real — no way to check a seller's history, no way to know if the same ticket has already been sold twice, no way to prove it's genuine at the door.

Scalpers post duplicate listings for tickets they don't have, take the money, and vanish. Legit fans reselling a ticket they can't use get lumped in with them, because platforms have no fast way to tell the two apart at scale.

The goal: trust that's computed, not assumed — a ticket verifiable in seconds, not disputed after the fact.

// HOW IT WAS PUT TOGETHER

Built solo — every line, every deployment, every 2am bug. Here's what each piece does and why it exists:

  • ML Fraud Detection — every listing hits a Scikit-learn model running as its own Flask microservice, scoring price deviation, account age, and daily listing volume before it ever goes public. High-risk listings get flagged before buyers see them, not after.
  • Real-Time via Socket.io — the second a ticket sells, a WebSocket event wipes that listing from every connected screen instantly. No polling, no risk of selling the same ticket twice.
  • Two Databases, Split by Purpose — MongoDB Atlas handles live transactional reads/writes; PostgreSQL on Supabase absorbs heavy analytics queries separately, so reporting never slows down the live marketplace.
  • JWT + QR Verification — every purchase generates a single-use QR cryptographically tied to that buyer and ticket. Scanned once, then dead — kills the screenshot-and-resell scam.
  • 3 Services, Deployed Independently — React, Node API, and the Flask ML service each deploy on their own. Retrain the model without touching the live app; if ML goes down, the marketplace just skips the fraud check instead of crashing.
// WHAT SHIPPED

Three independently deployed, independently scalable services. Real-time updates that eliminate double-booking. An automated fraud layer that catches high-risk listings before a human ever reviews them — and because it runs as its own microservice, scoring happens asynchronously without blocking a listing from loading.

Beyond the app itself, this is where I learned to actually operate a multi-service production system solo — coordinating deploys across three platforms, handling a service going down without taking the whole app with it, debugging real-time bugs that only surface with multiple concurrent users.

It's live, it's public, and I'm actively open to feedback — and to SDE / full-stack roles.

Architecture

Three independently deployed services, each doing one job well.

BROWSER User / Buyer FRONTEND React Vercel Socket.io client API Node.js / Express Render JWT auth · Socket.io server QR generation ML SERVICE Flask Render Scikit-learn fraud model Listing trust scoring DATABASE MongoDB Atlas users · tickets · orders DATABASE PostgreSQL Supabase · analytics CORE REQUEST PATH FRAUD SCORING PATH DATA PERSISTENCE

Try the Fraud Scoring Model

Adjust the sliders to see how the same signals used in production shift a listing's trust score.

0%
180 days
1
TRUST SCORE
92
LOW RISK

What the Model Catches

● 97% FRAUD RISK

Front Row — Below Face Value

New account, 14 listings posted today, price 60% under market average, unverified email.

● VERIFIED

Section 112, Row F

Account active 240+ days, single listing, priced near market average, verified email.

Deployed to Production

$ git push origin main
Vercel — building frontend...
Deployed → ticket-resale-phi.vercel.app
Render — deploying api service...
Render — deploying ml-service...
3/3 services healthy

Scan to Explore

QR code linking to the Ticket Resale Platform GitHub repository

Same QR pattern used in the app itself for ticket handoff verification — scan this one to jump straight to the source code.

Stack

Click any tag to see how it's actually used in this project.

SELECT A TAG

Click any technology above to see exactly how it's used in this build.

← Project on B&B Student Risk Dashboard →