Waitlist Playbook: How to Bank Your First Users in the 30 Days Before Launch

Most vibe coding projects die the same way: one evening you spend 6 hours building the product, excitedly post it to your social feeds, and then — silence. Dozens of "nice work!" comments, zero retained users. You tell yourself the product just isn't good enough, spend two more weeks polishing, launch a second time, and still nobody comes. The problem isn't the product. It's that on launch day you had no cards in your hand.

A waitlist solves exactly this: a playbook for turning "interested people" into "people waiting to use it" in the 30 days before launch. Note the wording — a waitlist is not a wishing well, it's a conversion funnel. What you want isn't 5,000 email addresses; it's a group of people who will actually open the product and actually pay on launch day. This guide gives you the complete playbook: choosing a model, minimal implementation code, a 30-day rhythm, anti-fraud, launch-day actions, metric thresholds, and how to fix the classic failure of a long waitlist with nobody showing up.

A waitlist is a conversion funnel, not an email collector: churn at every layer needs its own optimization.

Why vibe projects need a waitlist in particular

Big companies launch products on brand and budget. What does an indie vibe developer have? The hope that "the first batch of users all show up at the same time." The hardest part of a cold start isn't building the product — it's getting 100 people to use it in the same week. Users arriving in drips never generate feedback density: user A reports a bug on Monday, you fix it Wednesday, they've already forgotten about it; user B shows up Friday with a completely different problem. You're forever fighting timezone gaps with individual users, and you never get the feeling that "everyone is using it."

A waitlist solves three concrete problems:

• Validate demand before launch, not after. Put the landing page out for a week; if signup conversion is below 5%, your copy isn't landing — and changing copy at that point costs nothing. Discovering nobody wants it after the product is built costs two months.
• Stockpile launch ammunition. The algorithms on Product Hunt, V2EX, X and similar channels all reward "high-density engagement in a short window." Being able to mobilize 200 waitlist users to upvote and comment on launch day is a completely different game from posting alone.
• Force pre-sale thinking. The process of writing landing page copy forces you to answer "whose problem does this solve, exactly?" Many vibe projects get halfway built before realizing they can't answer that — a waitlist moves that question 30 days earlier.

A brutal but useful data point: among indie projects I've seen, nearly all of those with more than 200 DAU on launch day had some form of pre-launch list; of the projects that launched "naked," fewer than one in ten broke 50 DAU in week one. That's not mysticism, it's arithmetic — traffic needs a reservoir.

Four models, and how to choose

A waitlist isn't just "leave your email." By investment level and goal, there are four models:

Model 1: Pure email collection

One landing page + email input + "we'll notify you at launch." Cheapest to build, good for the stage where you're only validating copy and haven't committed to building. The downside is the shallowest funnel: signup-to-activation conversion is typically only 5–15%, because there's no commitment between the user and you.

Model 2: Queue + referral boost

The Robinhood playbook: after signing up you get a queue number, share your personal link, and jump N spots forward for every signup you bring. Fits products with social dynamics or scarce supply (AI tools, community products). The referral mechanism turns every signup into a distribution node, driving acquisition cost toward zero. The price is writing referral scoring logic and fighting fraud.

Model 3: Paid pre-order

Collect a small deposit before launch (e.g. $9), credited or refunded at launch. This is the strongest demand validation: people willing to pay and people willing to leave an email are two different species. Fits products with clear pricing and deliverables (templates, courses, SaaS annual plans). Caveat: taking money means making promises, and the cost of missing a deadline is ten times higher than with a free waitlist.

Model 4: Closed beta, invite-only

No public queue; application-based + manual review, invite codes released in batches. Fits complex products that need high-quality feedback (dev tools, AI agents). Small numbers but extreme feedback density — 50 well-chosen beta users beat 2,000 email signups. The downside is operational weight: every application needs a human look.

Decision table:

Dimension	Pure email	Queue + referral boost	Paid pre-order	Closed beta invites
Team size	1 person, minimal time	1–2 people, can write referral logic	1 person, product already built	1–3 people, can do manual review
Product type	Idea validation stage, no MVP yet	Tools / AI apps with a viral hook	SaaS / templates / courses, clear deliverable	Dev tools / complex agents
Core goal	Validate copy and direction	Low-cost acquisition + buzz	Validate willingness to pay + cash flow	High-quality feedback + polish
Signup→activation rate	5–15%	15–30%	60–90%	40–70%
Implementation cost	Half a day	2–3 days	1–2 days (incl. payments)	1 day + ongoing ops
Biggest risk	Long list, nobody shows up	Fraud, referral gaming	Missing deadlines	Drifting review standards

Advice for indie developers: default to Model 2 (queue + referral boost). It's the best balance of validation strength, acquisition efficiency, and implementation cost. The code in the next section is written for this model; for Model 1 just delete the referral logic, Model 3 adds a payment step after the form, and Model 4 replaces auto-confirmation with a manual review queue.

Minimal implementation: Next.js + Supabase in one day

Stack: Next.js App Router for the landing page and APIs, Supabase for the database, Resend for confirmation emails. All have free tiers; one person can get it running in a day. The code below implements "queue + referral boost + double opt-in" — the logic runs as-is, just fill in your environment variables.

Step 1: Create the table

Run in the Supabase SQL Editor:

-- Waitlist main table
create table waitlist_signups (
  id uuid primary key default gen_random_uuid(),
  email citext unique not null,
  name text,
  -- each person's personal referral code; referees enter this code
  referral_code text unique not null default substr(md5(random()::text), 1, 8),
  -- who referred them (stores the referrer's referral_code)
  referred_by text references waitlist_signups(referral_code),
  confirmed boolean not null default false,
  confirm_token text unique,
  unsubscribed boolean not null default false,
  created_at timestamptz not null default now()
);

create index idx_waitlist_referred_by on waitlist_signups(referred_by);
create index idx_waitlist_confirmed on waitlist_signups(confirmed);

-- Queue positions: live rank view ordered by confirmation time
create or replace view waitlist_queue as
select
  id,
  email,
  referral_code,
  created_at,
  row_number() over (order by created_at asc) as position
from waitlist_signups
where confirmed = true and unsubscribed = false;

Two design decisions worth noting: email uses the citext type for natural case-insensitive dedup; queue position is computed live via a view instead of a physical column — avoiding rank corruption under concurrent writes.

Step 2: Signup endpoint (dedup + disposable-email guard)

app/api/waitlist/route.ts:

import { NextRequest, NextResponse } from 'next/server';
import { createClient } from '@supabase/supabase-js';
import { Resend } from 'resend';
import crypto from 'crypto';

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_KEY! // server-side key — never expose to the client
);
const resend = new Resend(process.env.RESEND_API_KEY);

// Disposable email domain blocklist (in production, use a live
// verification API like Verifalia for real-time checks)
const DISPOSABLE_DOMAINS = new Set([
  'tempmail.com', '10minutemail.com', 'guerrillamail.com',
  'mailinator.com', 'throwawaymail.com', 'yopmail.com',
]);

export async function POST(req: NextRequest) {
  const { email, name, referredBy } = await req.json();

  // 1. Basic validation
  const cleanEmail = String(email || '').trim().toLowerCase();
  if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(cleanEmail)) {
    return NextResponse.json({ error: 'Invalid email format' }, { status: 400 });
  }
  const domain = cleanEmail.split('@')[1];
  if (DISPOSABLE_DOMAINS.has(domain)) {
    return NextResponse.json(
      { error: 'Please use a regular email — temporary addresses cannot receive invites' },
      { status: 400 }
    );
  }

  // 2. Dedup: return the existing record (idempotent, no error)
  const { data: existing } = await supabase
    .from('waitlist_signups')
    .select('id, referral_code, confirmed')
    .eq('email', cleanEmail)
    .maybeSingle();
  if (existing) {
    return NextResponse.json({
      ok: true,
      deduped: true,
      referralCode: existing.referral_code,
      confirmed: existing.confirmed,
    });
  }

  // 3. Validate the referral code (a wrong code never blocks signup,
  //    it just doesn't count as a referral)
  let validReferrer: string | null = null;
  if (referredBy) {
    const { data: referrer } = await supabase
      .from('waitlist_signups')
      .select('referral_code')
      .eq('referral_code', String(referredBy).trim())
      .maybeSingle();
    if (referrer) validReferrer = referrer.referral_code;
  }

  // 4. Insert + generate confirmation token
  const confirmToken = crypto.randomBytes(32).toString('hex');
  const { data, error } = await supabase
    .from('waitlist_signups')
    .insert({
      email: cleanEmail,
      name: String(name || '').slice(0, 50) || null,
      referred_by: validReferrer,
      confirm_token: confirmToken,
    })
    .select('referral_code')
    .single();
  if (error) {
    // Race-safe fallback: treat unique-key conflicts as idempotent
    if (error.code === '23505') {
      return NextResponse.json({ ok: true, deduped: true });
    }
    return NextResponse.json({ error: 'Signup failed, please retry' }, { status: 500 });
  }

  // 5. Send the double opt-in confirmation email
  const confirmUrl = `${process.env.NEXT_PUBLIC_SITE_URL}/api/waitlist/confirm?token=${confirmToken}`;
  await resend.emails.send({
    from: 'Your Product <hello@yourdomain.com>',
    to: cleanEmail,
    subject: 'Confirm your waitlist spot',
    html: `<p>Hi! Click the link below to confirm your spot — only confirmed signups join the queue:</p>
<p><a href="${confirmUrl}">Confirm my spot</a></p>
<p>After confirming you'll get a personal referral link: every friend you invite moves you 10 spots forward.</p>`,
  });

  return NextResponse.json({
    ok: true,
    referralCode: data.referral_code,
    message: 'Confirmation email sent — please check your inbox',
  });
}

Key point: double opt-in is not optional. A waitlist without a confirmation step is 30%+ throwaway addresses and bots; on launch day your emails hard-bounce and torch your sending domain's reputation. One extra click buys you a list that's twice as clean.

Step 3: Confirmation endpoint

app/api/waitlist/confirm/route.ts:

import { NextRequest, NextResponse } from 'next/server';
import { createClient } from '@supabase/supabase-js';

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_KEY!
);

export async function GET(req: NextRequest) {
  const token = new URL(req.url).searchParams.get('token');
  if (!token) return NextResponse.redirect(new URL('/waitlist?error=bad_token', req.url));

  const { data } = await supabase
    .from('waitlist_signups')
    .select('id, confirmed, referral_code')
    .eq('confirm_token', token)
    .maybeSingle();

  if (!data) return NextResponse.redirect(new URL('/waitlist?error=bad_token', req.url));

  if (!data.confirmed) {
    await supabase
      .from('waitlist_signups')
      .update({ confirmed: true, confirm_token: null }) // single-use token: burn after use
      .eq('id', data.id);
  }
  // Redirect to the success page with the referral code for easy sharing
  return NextResponse.redirect(
    new URL(`/waitlist/success?code=${data.referral_code}`, req.url)
  );
}

Step 4: Queue position lookup

What users love most is seeing "how many people are ahead of me." A dedicated endpoint, app/api/waitlist/status/route.ts:

import { NextRequest, NextResponse } from 'next/server';
import { createClient } from '@supabase/supabase-js';

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_KEY!
);

// Referral boost rule: +10 spots per confirmed referral (tune as needed)
const BOOST_PER_REFERRAL = 10;

export async function GET(req: NextRequest) {
  const code = new URL(req.url).searchParams.get('code');
  if (!code) return NextResponse.json({ error: 'Missing referral code' }, { status: 400 });

  // My raw position
  const { data: me } = await supabase
    .from('waitlist_queue')
    .select('position')
    .eq('referral_code', code)
    .maybeSingle();
  if (!me) return NextResponse.json({ error: 'Not found' }, { status: 404 });

  // My confirmed referrals
  const { count: referrals } = await supabase
    .from('waitlist_signups')
    .select('id', { count: 'exact', head: true })
    .eq('referred_by', code)
    .eq('confirmed', true);

  // Total queue size
  const { count: total } = await supabase
    .from('waitlist_queue')
    .select('id', { count: 'exact', head: true });

  const boost = (referrals ?? 0) * BOOST_PER_REFERRAL;
  const effectivePosition = Math.max(1, me.position - boost);

  return NextResponse.json({
    rawPosition: me.position,
    referrals: referrals ?? 0,
    boost,
    position: effectivePosition, // boosted effective rank
    total: total ?? 0,
  });
}

The success page calls this endpoint and shows "You're #128 of 2,034 — invite 3 friends to jump to #98." That live feedback is the fuel of the referral loop. Note the rank is a "soft rank": the boost only affects invite-batch priority, never the raw order in the database — no concurrency disputes.

Step 5: Launch-day batch scoring

Don't let everyone in at once on launch day. Sort by an "effective score" and release in batches:

// scripts/invite-batches.ts — run with tsx or ts-node
import { createClient } from '@supabase/supabase-js';

const supabase = createClient(process.env.NEXT_PUBLIC_SUPABASE_URL!, process.env.SUPABASE_SERVICE_KEY!);

// Scoring: earlier signups weigh more, each confirmed referral adds points
function scoreOf(row: { created_at: string; referralCount: number }) {
  const daysSinceSignup =
    (Date.now() - new Date(row.created_at).getTime()) / 86400000;
  return row.referralCount * 100 + Math.max(0, 30 - daysSinceSignup);
}

async function main() {
  const batchSize = Number(process.argv[2] ?? 100); // how many to invite this round
  const { data: users } = await supabase
    .from('waitlist_signups')
    .select('id, email, created_at')
    .eq('confirmed', true)
    .eq('unsubscribed', false);

  // Count each person's confirmed referrals
  const { data: all } = await supabase
    .from('waitlist_signups')
    .select('referred_by')
    .eq('confirmed', true);
  const refCount = new Map<string, number>();
  for (const r of all ?? []) {
    if (r.referred_by) refCount.set(r.referred_by, (refCount.get(r.referred_by) ?? 0) + 1);
  }
  // Note: referred_by stores the referral_code; simplified for demo.
  // In production, add a referred_by_id (uuid) FK column to avoid
  // misalignment if codes ever change.

  const ranked = (users ?? [])
    .map((u) => ({ ...u, score: scoreOf({ created_at: u.created_at, referralCount: 0 }) }))
    .sort((a, b) => b.score - a.score);

  const batch = ranked.slice(0, batchSize);
  console.log(`Inviting ${batch.length} users this batch, cutoff score >= ${batch.at(-1)?.score.toFixed(1)}`);
  // TODO: send invite emails via Resend here, or write to an invite_codes table
  for (const u of batch) console.log(u.email);
}
main();

The 30-day rhythm: what to do each week

The technical build is 20% of a waitlist; the other 80% is the 30-day operating rhythm. Week by week:

Week	Goal	Action checklist	Channels / messaging notes
Week 1 Ship it	Landing page live, first 100 seed signups	Launch landing page + signup form; write 3 headline variants for A/B; DM 20 friends for a private preview	Template: "I'm building a small tool that helps XX solve XX — private beta next week, want me to hold you a front-row spot? Leave me your email." DMs convert at 30%+; send them one by one, with names, never as a blast.
Week 2 Content warm-up	Content-driven growth to 500 signups	Publish 2–3 build-in-public posts; record one 60-second product demo; add a live "XXX people in queue" counter to the landing page	Pick 2 home channels by audience (X / Reddit / Indie Hackers / Xiaohongshu). Post structure: pain scenario → 30-second demo → "beta queue open, link in comments." Don't just post the product — post the messy process; process posts spread 5x better than product posts.
Week 3 Leverage	Push to 1,500–2,000 signups	Recruit 3–5 micro-KOLs (10k–50k followers are easier to win than big names) with beta access; post in 2–3 relevant communities/forums; turn on referral boost + leaderboard	KOL pitch: "Launching next week — here's 20 queue-jump beta codes you can give your followers." Frame it as "a perk for their audience," not "an ad for me" — acceptance rates are worlds apart. Lurk 3 days in a community before posting; learn the rules first.
Week 4 Countdown	Heat the list up, maximize launch-day conversion	Send 3 warm-up emails (D-7 feature tease / D-3 beta-user testimonials / D-1 launch time + exclusive early-bird pricing); put a countdown on the landing page; show up in communities daily	Don't write "coming soon" subject lines — write concrete hooks: "Friday 10am: your queue number #128 activates (includes 48-hour early-bird 50% off)." Specifics beat vibes.

Non-negotiable weekly check: look at the numbers (signups, confirmation rate, referral K-factor), kill channels that aren't moving, double down on the one that is. Over 30 days you'll try 6–8 channels; usually only 2 produce — that's normal. Waitlist ops is rapid experimentation.

Tool stack: the minimum setup for a one-person waitlist

Don't agonize over tools; at the waitlist stage, good enough wins:

• Landing page: hand-roll it in Next.js if you code — one day, and the APIs above plug right in. Otherwise Framer / Webflow for drag-and-drop, with the form wired to Supabase or Tally. What matters: fast load, no mobile breakage — over half your signups come from phones.
• Email: Resend (developer-friendly, free tier covers a few thousand sends) or Loops (built for indies, nice templates). Set up SPF/DKIM/DMARC on your sending domain, or confirmation emails land in spam and your double opt-in is dead on arrival.
• Analytics: skip heavy BI early. Three SQL queries a week is enough: new confirmations per day, referral K-factor, signups by source (add a hidden utm_source field to the form). Consider PostHog once you pass 5,000.
• Leaderboard / countdown frontend: the success page renders rank from the status endpoint in Step 4; a client-side setInterval countdown is fine — no need to drag in WebSockets for this.

Total cost: a domain + Resend free tier + Supabase free tier — under $15/month. At the waitlist stage, spend money and time on content and channels, not infrastructure.

Anti-fraud and list hygiene: a long list full of water

Queue + referral mechanics will attract farmers. In a 2,000-person waitlist, if 40% is farmed, your launch-day conversion gets diluted beyond recognition. Four defenses:

• Disposable-email detection. The signup endpoint already blocklists domains — that's layer one. Layer two: plug in a live email-verification API (Verifalia, MillionVerifier) at signup to check the address actually exists and isn't catch-all. Free tiers usually cover the waitlist stage.
• Boost-farming detection. Watch three signals: many signups from one IP in a short window; all referees inside the same /24 subnet; star-shaped referral chains ("one referrer, ten referees") with zero email opens from the referees. Two signals = flag as suspicious; down-weight them in launch batches rather than deleting outright (avoid false positives on real users).
• Dedup strategy. The citext unique key handles case variants; add one normalization layer: name+tag@gmail.com and name@gmail.com are the same person — strip + suffixes before insert (cleanEmail.replace(/\+[^@]*@/, '@')), and strip dots for Gmail domains (Gmail ignores them).
• Confirmation rate is the best filter. Double opt-in alone screens out 20–30% of low-quality signups. Three days before launch, send one last reminder to "signed up but unconfirmed" users; anyone still unconfirmed gets dropped from the invite batches — don't mourn them, they were never coming.

One principle: 500 real humans beat 5,000 numbers. When investors or friends ask, quote confirmed users, never raw signups — build that habit from day one.

Launch day: five moves to turn the list into users

1. Release invites in three batches, 4–6 hours apart. Batch one: referral champions + the earliest 100 signups (your evangelists); batch two: the middle 60%; batch three: the rest + same-day signups. Batching keeps your servers alive, gives you time to fix bugs batch one finds, and manufactures "hasn't reached me yet" scarcity chatter.
2. Three-email sequence, on a strict cadence. Email one (with the invite): "Your invite code is XXX, valid 48 hours." Email two (24h later, only to the unactivated): "Your code expires in 24 hours — here's a 3-minute getting-started guide." Email three (2h before expiry): "Last call." One email, one message, one button each.
3. Scarcity must be real. "First 500 get lifetime 50% off" is fine; "today only" extended every day is not. Users smell fake scarcity instantly — one false alarm and the whole list's trust is gone. Real scarcity done right: an early-bird quota with a live "37 seats left" counter.
4. Be there in person on launch day. Product Hunt, Reddit, your communities — reply to every comment within 12 hours of posting, everywhere you posted. Waitlist users seeing the founder show up personally activates at a visibly higher rate. That's a one-person team's asymmetric advantage over big companies; don't waste it.
5. Do the accounting 24 hours later. Track: invites sent → email open rate → click rate → activations → paying users. Pin every drop-off to a concrete cause and write it into a retro doc. That's the starting point for your next waitlist.

Metrics: how big a waitlist counts as "validated"

Three core metrics, reviewed weekly:

• Signup→activation rate = activations within 7 days of launch / confirmed signups. Healthy: 15–30% for Model 2 (queue + referral); below 10% means warm-up failed or the product doesn't match the landing page's promises.
• Referral K-factor = referred signups / total signups. K > 0.3 means the referral loop is spinning; K < 0.1 means people signed up and forgot you — strengthen the referral hook on the success page and in emails.
• Email open rate = warm-up email opens / sends. Healthy waitlist email open rates run 40–60% (far above the ~20% of ordinary marketing mail). Below 30% means the list is full of dead weight, or your subject lines read like spam.

So how big is "validated"? An actionable threshold: ≥ 300 confirmed users, ≥ 40% email open rate, and ≥ 20% of signups from referrals. All three together mean: people want it (volume), they're real (open rate), and they'll spread it (referrals). Launch at that point and you'll very likely get 50–100 real activations on day one — a successful cold start for an indie project.

Conversely, if 30 days only got you 80 confirmed users, don't force the launch. Go back, rewrite the landing copy, switch channels, run two more weeks. A waitlist's greatest value is letting you "fail cheap": discovering nobody wants it in 30 days beats discovering it 3 months after building the product, a hundred times over.

Failure mode: a long queue, but nobody shows up on launch day

The most common way waitlists die. 3,000 on the list, 50 show up at launch. Three usual causes and fixes:

Cause 1: Radio silence during warm-up — users forgot who you are

Zero contact for 30 days after signup; when the launch email arrives, the user thinks "who is this?" Fix: the 3 warm-up emails from the rhythm table are the floor; better is a weekly "build log" in weeks 2–3 — what shipped, what got fixed, what beta users said. Make users feel they're following a series, not waiting on a stranger.

Cause 2: Landing-page promises don't match the actual product

To pump signup numbers the copy oversells; the product opens to something else entirely. Users feel tricked, churn instantly, and leave a bad review on the way out. Fix: verify every landing-page claim line by line before launch. The week-2 demo video must be recorded on the real product, not concept art. Fewer signups beats burned trust.

Cause 3: Too much friction in the invite flow

Copy the invite code, go to another page to redeem it, verify email again after redeeming — every extra step costs you 20%. Fix: one-click magic-link login from the invite; compress "receive invite → using the product" to 2 steps max. Walk the flow yourself three times before launch, stopwatch in hand — over 3 minutes is a fail.

One last word: a waitlist is not a wishing well, it's a conversion funnel. Every layer of the funnel — signup, confirmation, warm-up opens, launch activation, payment — gets its own numbers and its own optimization. 300 real humans who walk the whole funnel beat 3,000 email addresses lying in a database. Thirty days from now at launch, what you want isn't buzz — it's the first batch of people who stay.