等候名单 Waitlist 落地实战：上线前 30 天攒出第一批用户

大多数 vibe coding 项目死掉的方式都一样：某天晚上你花 6 小时把产品做出来，激动地发到朋友圈和即刻，然后——沉没。几十个"支持一下"，零个留存用户。你安慰自己是产品还不够好，于是又花两周打磨，上线第二次，还是没人来。问题不在产品，在你上线那天手里一张牌都没有。

等候名单（waitlist）就是解决这个问题的：一套在产品上线前 30 天，把"感兴趣的人"变成"等着用的人"的打法。注意措辞——waitlist 不是许愿池，是转化漏斗。你要的不是 5000 个邮箱地址，而是一批在 launch 当天会真的打开产品、真的付费的人。这篇文章给出一套完整做法：选型、最小实现代码、30 天节奏表、反作弊、launch 当天动作、指标判断线，以及排队很长但 launch 当天没人来的解法。

waitlist 的本质是转化漏斗，不是邮箱收集器：每一层的流失都要单独优化。

为什么 vibe 项目尤其需要 waitlist

大公司做产品靠品牌和预算，vibe 独立开发者靠什么？靠"第一批用户在同一时间出现"。冷启动最难的不是做产品，是让 100 个人在同一周用上它。零散到来的用户产生不了反馈密度：A 用户周一提了 bug，你周三修好，他已经忘了这事；B 用户周五来了，遇到的是另一个问题。你永远在和单个用户的时差搏斗，永远凑不出"大家都在用"的体感。

waitlist 解决三个具体问题：

• 上线前验证需求，而非上线后验证。落地页放出去一周，注册转化率低于 5%，说明你的描述没击中人——这时候改文案的成本是零。等产品做完再发现没人要，成本是两个月。
• 攒启动弹药。Product Hunt、V2EX、即刻这些渠道的算法都奖励"短时间高密度互动"。launch 当天你能动员 200 个 waitlist 用户去点赞评论，和你一个人发帖，完全是两个游戏。
• 逼自己做预售型思考。写落地页文案的过程，就是被迫回答"这东西到底解决谁的什么问题"的过程。很多 vibe 项目做到一半才发现自己答不上来——waitlist 把这个问题提前了 30 天。

一个残酷但有用的数据点：我见过的独立项目里，launch 当天 DAU 超过 200 的，几乎都有某种形式的预热名单；而"裸上"的项目，首周 DAU 能过 50 的不到一成。这不是玄学，是算术——流量需要蓄水池。

四种形态，怎么选

waitlist 不是只有"留邮箱"一种。按投入和目标，分四种形态：

形态一：纯邮箱收集

一个落地页 + 邮箱输入框 + "上线通知你"。成本最低，适合只想验证文案、还没决定做不做的阶段。缺点是转化漏斗最浅：注册到激活的转化率通常只有 5–15%，因为用户和你之间没有任何承诺。

形态二：排队 + 推荐加速

Robinhood 当年玩的那套：注册后给你一个排队号码，分享专属链接、每带来一个注册就往前跳 N 位。适合有社交属性或供给稀缺的产品（AI 工具、社区型产品）。推荐机制把每个注册用户变成你的分销节点，获客成本趋近于零。代价是你要写推荐计分逻辑，还要防刷。

形态三：付费预定

上线前收一笔小额定金（比如 9.9 元 / 9 美元），launch 后抵扣或退款。这是最强的需求验证：愿意掏钱的人和愿意留邮箱的人，完全是两个物种。适合客单价明确、有清晰交付物的产品（模板、课程、SaaS 年费版）。注意：收钱就意味着承诺，跳票的代价比免费 waitlist 大十倍。

形态四：封闭内测邀请制

不公开排队，申请制 + 人工审核，分批发放邀请码。适合需要高质量反馈的复杂产品（开发者工具、AI Agent）。人数少但反馈密度极高，50 个精准内测用户顶 2000 个邮箱注册。缺点是运营重，每个申请都要看。

决策表：

维度	纯邮箱收集	排队+推荐加速	付费预定	封闭内测邀请制
团队规模	1 人，时间极少	1–2 人，能写推荐逻辑	1 人，但产品已成型	1–3 人，能做人工审核
产品类型	想法验证期，MVP 还没影	工具/AI 应用，有传播点	SaaS/模板/课程，交付物清晰	开发者工具/复杂 Agent
核心目标	验证文案和方向	低成本获客+造势	验证付费意愿+回笼资金	高质量反馈+打磨
注册→激活转化率	5–15%	15–30%	60–90%	40–70%
实现成本	半天	2–3 天	1–2 天（含支付）	1 天+持续运营
最大风险	名单很长但没人来	刷榜、推荐作弊	跳票被骂	审核标准飘忽

给独立开发者的建议：默认选形态二（排队+推荐加速）。它在验证强度、获客效率、实现成本之间是最均衡的。下面第 3 节的代码就是按这个形态写的；如果你选形态一，把推荐逻辑删掉即可，形态三在表单后加一步支付，形态四把自动确认改成人工审核队列。

最小实现：Next.js + Supabase，一天落地

技术选型：Next.js App Router 做落地页和 API，Supabase 做数据库，Resend 发确认邮件。全部有免费额度，一个人一天能跑通。下面代码按"排队+推荐加速 + double opt-in"形态写，逻辑可直接运行，只需填环境变量。

第一步：建表

在 Supabase SQL Editor 里执行：

-- 等候名单主表
create table waitlist_signups (
  id uuid primary key default gen_random_uuid(),
  email citext unique not null,
  name text,
  -- 每个人的专属推荐码，被推荐人填这个码
  referral_code text unique not null default substr(md5(random()::text), 1, 8),
  -- 谁推荐的（存推荐人的 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);

-- 排队名次：按确认时间排序的实时名次视图
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;

注意两个设计决策：email 用 citext 类型，天然大小写不敏感去重；排队名次不用物理字段存，而是用视图实时算——避免并发写入时名次错乱。

第二步：注册接口（防重复 + 临时邮箱拦截）

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! // 服务端 key，注意不要暴露给前端
);
const resend = new Resend(process.env.RESEND_API_KEY);

// 一次性邮箱域名黑名单（生产环境建议接 verifalia 等 API 做实时校验）
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. 基础校验
  const cleanEmail = String(email || '').trim().toLowerCase();
  if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(cleanEmail)) {
    return NextResponse.json({ error: '邮箱格式不正确' }, { status: 400 });
  }
  const domain = cleanEmail.split('@')[1];
  if (DISPOSABLE_DOMAINS.has(domain)) {
    return NextResponse.json(
      { error: '请使用常用邮箱注册，临时邮箱无法收到邀请' },
      { status: 400 }
    );
  }

  // 2. 防重复：已存在则直接返回已有记录（幂等，不报错）
  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. 校验推荐码（填错码也不阻断注册，只是不计推荐关系）
  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. 写入 + 生成确认 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) {
    // 并发重复提交兜底：唯一键冲突时按幂等处理
    if (error.code === '23505') {
      return NextResponse.json({ ok: true, deduped: true });
    }
    return NextResponse.json({ error: '注册失败，请稍后重试' }, { status: 500 });
  }

  // 5. 发送 double opt-in 确认邮件
  const confirmUrl = `${process.env.NEXT_PUBLIC_SITE_URL}/api/waitlist/confirm?token=${confirmToken}`;
  await resend.emails.send({
    from: '你的产品名 <hello@你的域名.com>',
    to: cleanEmail,
    subject: '请确认你的等候名单席位',
    html: `<p>你好！点击下方链接确认你的席位，确认后才能参与排队：</p>
<p><a href="${confirmUrl}">确认我的席位</a></p>
<p>确认后你会得到专属推荐链接，每邀请 1 位朋友注册，你的排队名次前进 10 位。</p>`,
  });

  return NextResponse.json({
    ok: true,
    referralCode: data.referral_code,
    message: '确认邮件已发送，请查收',
  });
}

关键点：double opt-in（双重确认）不是可选项。没有确认环节的 waitlist，30% 以上是随手填的假邮箱和机器人，launch 当天邮件发出去全是硬退，还会搞坏你的发信域名信誉。多一步点击，换来的是名单质量翻倍。

第三步：确认接口

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 }) // token 一次性，用完即焚
      .eq('id', data.id);
  }
  // 跳到成功页，带上推荐码方便分享
  return NextResponse.redirect(
    new URL(`/waitlist/success?code=${data.referral_code}`, req.url)
  );
}

第四步：排队名次查询

用户最爱看的就是"前面还有多少人"。单独一个接口 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!
);

// 推荐加速规则：每带来 1 个"已确认"的被推荐人，前进 10 位（可按需调参）
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: '缺少推荐码' }, { status: 400 });

  // 我的原始名次
  const { data: me } = await supabase
    .from('waitlist_queue')
    .select('position')
    .eq('referral_code', code)
    .maybeSingle();
  if (!me) return NextResponse.json({ error: '未找到' }, { status: 404 });

  // 我带来的已确认注册数
  const { count: referrals } = await supabase
    .from('waitlist_signups')
    .select('id', { count: 'exact', head: true })
    .eq('referred_by', code)
    .eq('confirmed', true);

  // 总人数
  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, // 加速后的实际名次
    total: total ?? 0,
  });
}

前端 success 页调这个接口，展示"你的排名 #128 / 2034，邀请 3 位好友可前进到 #98"——这种实时反馈是推荐机制的燃料。注意名次是"软排名"：加速只影响邀请批次的优先级，不改数据库里的原始顺序，避免并发争议。

第五步：Launch 分批邀请的计分逻辑

launch 当天不要一次性全放出去。按"有效分数"排序分批：

// scripts/invite-batches.ts —— 用 tsx 或 ts-node 运行
import { createClient } from '@supabase/supabase-js';

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

// 计分规则：越早注册权重越高，每带来一个确认用户加分
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); // 本批放多少人
  const { data: users } = await supabase
    .from('waitlist_signups')
    .select('id, email, created_at')
    .eq('confirmed', true)
    .eq('unsubscribed', false);

  // 统计每人的有效推荐数
  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);
  }
  // 注意：referred_by 存的是 referral_code，这里简化演示；
  // 生产环境建议在 signups 表加 referred_by_id(uuid) 外键，避免 code 变更导致错位

  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(`本批邀请 ${batch.length} 人，分数线 score >= ${batch.at(-1)?.score.toFixed(1)}`);
  // TODO: 在这里调 Resend 发邀请邮件，或写入 invite_codes 表生成邀请码
  for (const u of batch) console.log(u.email);
}
main();

上线前 30 天节奏表：每周做什么

waitlist 的技术实现只占 20%，剩下 80% 是 30 天的运营节奏。按周拆：

周次	目标	动作清单	渠道/话术要点
第 1 周 落地	落地页上线，拿到前 100 个种子注册	上线落地页+注册表单；写 3 版 headline 做 A/B；给 20 个朋友发私信内测	话术模板："我在做一个帮 XX 解决 XX 的小工具，下周上线内测，留个邮箱我给你留前排位置？"——私信转化率通常 30%+，别群发，要一个一个发，带名字。
第 2 周 内容预热	靠内容把注册做到 500	发 2–3 篇构建过程（build in public）帖子；录 1 个 60 秒产品演示视频；落地页加"已排队 XXX 人"实时计数	即刻/V2EX/推特/小红书（按受众选 2 个主阵地）。帖子结构：痛点场景 → 30 秒演示 → "内测排队中，链接在评论区"。不要只发产品，要发"血泪过程"，过程帖的传播是产品帖的 5 倍。
第 3 周 借力	冲到 1500–2000 注册	找 3–5 个小 KOL（粉丝 1–5 万的比大 V 好谈）送内测资格；去 2–3 个相关社群/论坛发帖；启动推荐加速，上线排行榜	给 KOL 的话术："产品下周 launch，给你 20 个免排队内测码，你可以发给粉丝。"——给对方"发福利"而不是"打广告"，接受度完全不同。社群发帖前先潜水 3 天，摸清版规。
第 4 周 倒计时	把名单"烧热"，launch 当天转化率拉满	发 3 封预热邮件（D-7 功能剧透 / D-3 内测用户评价 / D-1 上线时间+专属早鸟价）；落地页挂倒计时；社群每天冒泡一次	邮件标题别写"即将上线"，写具体的钩子："周五 10 点，你的排队号 #128 生效（含 48 小时早鸟 5 折）"。具体信息 > 氛围感。

每周雷打不动的检查项：看一次数据（注册数、确认率、推荐系数），砍掉没起量的渠道，把时间加到起量的那个上。30 天里你大概会试 6–8 个渠道，最后真正出量的通常只有 2 个——这很正常，waitlist 运营的本质就是快速试错。

工具栈：一个人搞定 waitlist 的最低配

别在工具上纠结，waitlist 阶段够用就行：

• 落地页：会写代码就直接 Next.js 手写，一天搞定，还能顺手把上面的 API 全接上；不会或想更快，Framer / Webflow 拖一个，表单接到 Supabase 或 Tally。关键是页面加载要快、移动端不能崩——一半以上的注册来自手机。
• 邮件：Resend（开发者友好，免费额度够发几千封）或 Loops（给独立开发者做的，模板好看）。发信域名一定要配 SPF/DKIM/DMARC，否则确认邮件进垃圾箱，你的 double opt-in 就白做了。
• 数据分析：早期别上重型 BI，每周跑三条 SQL 就够：当日新增确认数、推荐系数 K、各渠道来源占比（注册表单里加个 utm_source 隐藏字段）。等名单过 5000 再考虑 PostHog。
• 排行榜/倒计时前端：success 页调第 4 步的 status 接口渲染名次；倒计时用客户端 setInterval 就行，别为了这点东西引入 WebSocket。

总成本：域名 + Resend 免费档 + Supabase 免费档，一个月不到 100 块。waitlist 阶段把钱和时间花在内容和渠道上，别花在基建上。

反作弊与数据清洗：名单很长但全是水

排队+推荐机制一定会招来羊毛党。一个 2000 人的 waitlist，如果 40% 是刷的，你的 launch 当天转化率会被彻底稀释。四个手段：

• 临时邮箱识别。注册接口里已经做了域名黑名单，这是第一道。进阶做法：接实时邮箱验证 API（如 Verifalia、MillionVerifier），在注册时校验邮箱是否真实存在、是否为 catch-all。免费额度一般够 waitlist 阶段用。
• 刷榜识别。看三个信号：同一 IP 短时间内大量注册；被推荐人全部来自同一个 /24 IP 段；推荐链条呈"一传十"的星型且被推荐人零邮件打开。满足两条就标记可疑，launch 分批时降权而非直接删除（避免误伤真实用户）。
• 去重策略。邮箱 citext 唯一键解决大小写变体；再加一层归一化：Gmail 的 name+tag@gmail.com 和 name@gmail.com 是同一个人，入库前 strip 掉 + 后缀和 .（Gmail 忽略点号）。代码里加一行：cleanEmail.replace(/\+[^@]*@/, '@')，Gmail 域名再去点。
• 确认率是最好的清洗器。double opt-in 本身就会筛掉 20–30% 的低质量注册。launch 前 3 天，给"注册但未确认"的人发最后一封提醒，仍不确认的直接移出邀请批次——别心疼，他们本来也不会来。

一句话原则：宁要 500 个真人，不要 5000 个数字。投资人或朋友问起来，报"确认用户数"，别报"注册数"，从第一天就养成这个习惯。

Launch 当天：把名单变成用户的 5 个动作

1. 分三批放邀请，每批间隔 4–6 小时。第一批：推荐达人 + 最早注册的 100 人（你的"传教士"）；第二批：中间 60%；第三批：剩余 + 当天新注册。分批的目的是让服务器不炸、让你有时间修第一批用户发现的 bug，以及制造"还没轮到我"的稀缺讨论。
2. 邮件序列三封，节奏卡死。第一封（放码同时）："你的邀请码是 XXX，48 小时内有效"；第二封（24 小时后，只发给未激活的）："你的码还有 24 小时过期，3 分钟上手指南在这里"；第三封（过期前 2 小时）："最后提醒"。每封只讲一件事，只放一个按钮。
3. Scarcity 设计要真实。"前 500 名终身 5 折"可以，"仅限今天"然后天天延期不行。用户对假稀缺的嗅觉极其灵敏，一次狼来了，整个 waitlist 的信任就没了。真实稀缺的做法：早鸟价有名额计数器，实时显示"剩余 37 席"。
4. launch 当天你本人要在场。Product Hunt、V2EX、社群——每个你发帖的地方，发布后 12 小时内每条评论都要回。waitlist 用户看到创始人亲自下场，激活意愿会明显上升。这是 1 人团队相对大公司的不对称优势，别浪费。
5. 24 小时后算总账。统计：邀请发送数 → 邮件打开率 → 点击率 → 注册激活数 → 付费数。每个环节的流失都要定位到具体原因，写进复盘文档。这是你下一次做 waitlist 的起点。

指标：多少 waitlist 算"验证通过"

三个核心指标，每周看一次：

• 注册→激活转化率 = launch 后 7 天内激活数 / 确认注册数。健康线：形态二（排队+推荐）15–30%，低于 10% 说明预热没做到位或产品与落地页承诺脱节。
• 推荐系数 K = 被推荐注册数 / 总注册数。K > 0.3 说明推荐机制转起来了；K < 0.1 说明大家注册完就忘了你，得在 success 页和邮件里强化推荐钩子。
• 邮件打开率 = 预热邮件打开 / 发送。waitlist 邮件打开率健康线是 40–60%（远高于普通营销邮件的 20%）。如果低于 30%，说明名单里水货太多，或者你的标题写得像垃圾邮件。

那么，多少 waitlist 算"验证通过"？给一个可操作的判断线：确认用户 ≥ 300，且邮件打开率 ≥ 40%，且至少 20% 的注册来自推荐。三个条件同时满足，说明：有人要（数量）、是真人（打开率）、愿意传播（推荐）。这时候上线，launch 当天大概率能拿到 50–100 个真实激活用户——对独立项目来说，这就是成功的冷启动。

反过来，如果 30 天只攒到 80 个确认用户，别硬上。回去改落地页文案，换个渠道再跑两周。waitlist 最大的价值恰恰是让你"便宜地失败"：30 天发现没人要，比做完产品 3 个月发现没人要，强一百倍。

失败模式：排队很长，但 launch 当天没人来

这是 waitlist 最常见的死法。名单 3000 人，launch 当天来了 50 个。三个常见原因和解法：

原因一：预热期静默，用户忘了你是谁

注册后 30 天零联系，launch 邮件发出去，用户想的是"这谁啊"。解法：第 4 节的 3 封预热邮件是底线；更好的做法是第 2–3 周每周一封"构建周报"：这周做了什么功能、修了什么 bug、内测用户说了什么。让用户感觉自己在"追更"，而不是在等一个陌生人。

原因二：落地页承诺与产品实际脱节

为了冲注册数，文案写得天花乱坠，产品打开一看是另一回事。用户觉得被骗，一次性流失，还顺手给你差评。解法：落地页的每一句承诺，launch 前逐句核对。第 2 周的演示视频要用真实产品录制，别用概念图。宁可注册少一点，也别透支信任。

原因三：邀请机制 friction 太大

邀请码要复制、要去另一个页面兑换、兑换完还要再验证邮箱——每多一步，流失 20%。解法：邀请链接一点即登录（magic link），把"收到邀请 → 用上产品"的路径压到 2 步以内。launch 前自己走三遍流程，掐表计时，超过 3 分钟就是不合格。

最后说一句：waitlist 不是许愿池，是转化漏斗。漏斗的每一层——注册、确认、预热打开、launch 激活、付费——都要单独看数据、单独优化。300 个走完漏斗的真人，顶 3000 个躺在数据库里的邮箱。30 天后上线，你要的不是热闹，是第一批会留下来的人。