Building Quudos: a casting platform on Amazon Aurora + Vercel

#ai #aws #hackathon #vercel

I created this post for the purposes of entering the H0: Hack the Zero Stack with Vercel v0 and AWS Databases hackathon. #H0Hackathon

Inspiration — this one's personal

This started with my daughter. She's 13 and an aspiring actor — she's already worked on campaigns and shows from national commercials to a children's TV show, and walked NYC and Brooklyn fashion shows. Every time we went to an audition or recorded a self-tape, I saw how disconnected the whole process was: submissions over email, schedules buried in texts, files scattered across folders, and no clear view of where anything actually stood. I started talking to talent agencies in New York and LA, and they all said the same thing — they're still managing their talent by hand, and it doesn't scale. That's why I built Quudos.

The problem

Talent agencies run casting on a patchwork of spreadsheets, email threads, shared folders, and disconnected casting databases. Submissions get lost, callbacks slip, and there's no single place to see a campaign move from breakdown to booking. Quudos is the all-in-one operating system for talent agencies — manage your roster, launch casting campaigns, and track every submission through callback and booking. For this hackathon I put it on the zero stack: a front end on Vercel and Amazon Aurora PostgreSQL as the primary database.

The architecture

Frontend: an Angular single-page app on Vercel, with a v0-built marketing landing page in front of it.
API: a NestJS (Node) service using node-postgres with pooling, transactions, and advisory locks.
Primary database: Amazon Aurora PostgreSQL (Serverless v2) in us-east-1 — the system of record for every agency, talent profile, campaign, role, submission, and lifecycle event.
Auth: a managed auth provider issues JWTs that the API verifies; all application data lives in Aurora.

Why Aurora — and a deliberate data model

Casting is inherently relational, so I modeled it that way:

organizations (agencies) → users (admins + talent) → actor_profiles, actor_media, actor_documents
workflow_items (campaigns) → campaign_roles → assignments (submissions) → campaign_events (lifecycle)

Status is enforced with PostgreSQL enums — the campaign lifecycle (DRAFT → COLLECTING_SUBMISSIONS → SUBMITTED_TO_CASTING → CALLBACK → BOOKED → CLOSED) and the submission lifecycle (AWAITING_ACCEPT → ACCEPTED → UPLOADED → SUBMITTED → REVIEWED). The API uses transactions and pg_advisory_lock so concurrent updates from multiple agents stay consistent. Aurora Serverless v2 scales the same architecture from a solo agent to thousands of submissions.

What I built during the hackathon

Quudos existed before on hosted Postgres. During the submission period I provisioned Aurora Serverless v2, recreated the schema on Aurora, migrated the data into it, repointed the API's DATABASE_URL to the Aurora cluster, and deployed the frontend on Vercel with a v0 landing page.

What I learned

node-postgres + Aurora is seamless — Aurora speaks the standard Postgres protocol, so the data layer moved over with a connection-string change, not a rewrite.
A real relational model is a feature, not overhead — enums, transactions, and advisory locks make the casting workflow trustworthy, which is exactly what agencies need.
The "zero stack" is real — Vercel for the front end and Aurora for the back end gave me a production-shaped app fast.

What's next

Free-for-actors access connecting talent to multiple agencies and casting directors, a casting-director portal, an integrated payments/deal-memo module, AI (brief generation + booking-probability scoring), and Aurora DSQL for multi-region scale — taking Quudos from breakdown all the way to payment. Two agencies in NY/LA are already lined up to use it.

Built with: Angular · v0 · Vercel · NestJS · Node.js · Amazon Aurora PostgreSQL (Serverless v2) · node-postgres. Created for the #H0Hackathon.