标签：#hack

Nod is an approval API for AI agents, scripts, and workflows. The idea is simple: Your app wants to do something risky. Nod asks a human for approval. The human approves in Slack or web. Nod sends a signed callback. Your app continues safely. We built the web app on Vercel . The dashboard lets teams manage: Workspaces Members and roles Approval policies Slack channels API keys Callback endpoints Approval history For the database, we used Amazon Aurora PostgreSQL . Nod needs a strong relational database because approval data must be correct. An approval is not just a UI card. It has a lifecycle. pending -> approved pending -> rejected pending -> expired pending -> canceled Aurora stores the source of truth: Approval requests Human decisions Policy versions Webhook events Delivery attempts Audit logs The backend runs on AWS with Lambda workers. One worker sends Slack notifications. Another sends signed callbacks. Another expires old approvals. A typical flow looks like this: App or agent -> Nod API -> Aurora PostgreSQL -> Slack or web approval -> Signed callback -> App continues Vercel helped us move fast on the user experience. Aurora gave us the reliable data layer needed for real approvals. Together, they helped us build Nod as infrastructure, not just a demo.

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