Waitlyst — AI Fraud-Aware Waitlist Platform

Waitlyst: the waitlist platform that grows itself — and catches the people trying to cheat it

Comment

Inspiration

Every indie founder launching a product hits the same moment: they want to build hype before they're ready to ship, so they put up a waitlist. The good tools add referral mechanics so the list grows itself — but almost none of them seriously protect that mechanic once it's live. Fake signups, bot referrals, and self-referral chains quietly corrupt the leaderboard and waste real reward budget. A few established tools have started bolting on basic fraud filters, but they're typically simple rate-limit rules that are easy to evade and give the founder no real explanation of what was flagged or why. We wanted to build a waitlist platform where the leaderboard could actually be trusted, and where the founder reviewing flagged activity gets a real explanation instead of a black-box yes/no.

What it does

Waitlyst lets a founder create a branded waitlist campaign in minutes. Anyone can join through a public link with just an email — no account needed. Every participant gets a unique referral code, and successful referrals move them up a live leaderboard, the same growth loop companies like Robinhood used before launch. On top of that, Waitlyst sends signup and referral events to an LLM that analyzes patterns — IP velocity, suspicious referral chains, self-referrals — and surfaces flagged participants with a risk score and plain-language reasoning the founder can actually read and act on. Founders also get AI-generated reward tier suggestions based on their campaign description, and can upgrade to a Pro plan via Stripe for unlimited campaigns and fraud detection.

How we built it

The frontend is Next.js with the App Router, styled with Tailwind and Framer Motion for a dark, editorial design rather than a generic SaaS template. The backend uses Amazon Aurora DSQL as the primary relational store for founders, campaigns, participants, and leaderboard ranks — chosen because the leaderboard needs strict consistency when multiple referrals land close together. DynamoDB handles high-volume referral and signup event logging that feeds the fraud detection pipeline, a deliberate split between a consistency- critical workload and a high-throughput, append-only one. Fraud analysis and reward tier suggestions are powered by Groq running Llama 3.3, billing runs through Stripe Checkout and webhooks, and auth is a simple email/password system with JWT sessions, chosen after OAuth setup proved unreliable mid-build — a working simple flow beat a broken complex one. The whole thing is deployed on Vercel.

Challenges we ran into

Aurora DSQL has real, undocumented-feeling constraints that took genuine debugging time to uncover: it doesn't support FOREIGN KEY constraints at all, so referential integrity between campaigns and participants had to be enforced at the application layer with explicit existence checks before every insert. Its index syntax also differs from standard Postgres — indexes must be created with CREATE INDEX ASYNC, and sort order (DESC) isn't supported on indexes, only in query ORDER BY clauses. We also lost real time to an expired Vercel OIDC token silently causing the app to fall back to a local Postgres database without us immediately realizing it — a sharp lesson in always verifying against real query output rather than trusting a success message. Separately, our DynamoDB table ended up provisioned in a different AWS account than Aurora DSQL, due to how permissions were scoped through Vercel's integration; rather than forcing both into one account, we isolated the two databases' credentials completely so each connects independently and correctly.

Accomplishments that we're proud of

Getting Aurora DSQL working correctly with a clean, deliberate data model despite real platform-specific quirks that aren't well documented yet. Building fraud detection that returns specific, explainable risk scores with real reasoning rather than a black-box flag — a meaningfully different approach from the rule-based filters we found in existing waitlist tools. And keeping the product demoable and stable under serious time pressure by making disciplined scope decisions, like choosing a simplified refresh-based leaderboard over a fragile real-time implementation, because a working simple feature beats a broken sophisticated one.

What we learned

How much production AWS infrastructure differs from assumptions, especially for a database as new as Aurora DSQL. We also learned the real value of verifying claims against actual query results at every step rather than trusting a tool's "this works now" summary — several of our hardest bugs were only caught by manually querying the database directly instead of trusting the application layer's success response. And we learned that an honest architecture story — including the constraints we hit and the tradeoffs we made — is more convincing than pretending everything was seamless.

What's next for Waitlyst

Moving the leaderboard from refresh-based to genuinely real-time using the SSE route already scaffolded in the codebase, expanding fraud detection to act automatically on high-confidence flags instead of requiring manual founder review, and adding reward tier customization driven by real usage data rather than just AI suggestions at campaign creation.

Built With

Share this project:

Updates

Submission history