Design a referral waitlist for your product

A referral waitlist works when people want your product before they can use it and know specific friends who'd want it too. That's why it suits products people use with others, such as a team tool, a payments app, or a social product, where inviting a friend makes the product better for both of them. It also suits launches with a real limit on how many people you can take at once.

Kite checks your launch against those conditions before it designs anything. It looks at who your customers are, how they found you so far, and whether they tend to work in groups. If you're launching a project-management tool for design agencies, a waitlist makes sense, because every agency that joins has colleagues and peers it can invite. If you're opening a single bakery, Kite will likely suggest a plain waitlist with an opening-day offer instead, and a customer referral program once you have regulars to ask.

You build it by settling a handful of rules before anyone writes code. Kite proposes each rule with its reasoning, and you agree on the final set.

• What counts as a referral. Kite usually recommends counting a referral only when the friend signs up and confirms their email address. Counting clicks or unconfirmed signups invites people to game the list.
• How far each referral moves someone. Kite sizes the jump so that a few invites make a visible difference. Say Maya signs up as number 4,212 and each confirmed friend moves her up 100 places. After five friends join, she's at number 3,712, and she can see that the effort worked.
• Milestones worth reaching. Some waitlists add rewards at set points, such as skipping straight to the next group let in after three friends join, or a call with the founders after ten. Kite can also design branded merchandise as a milestone reward and order it through its built-in Printify connection.
• What people see after they sign up. A status page shows their place in line, how many people are behind them, their personal link, and how many more friends they need for the next milestone.
• How people get let in. Kite recommends letting people in from the front of the line in regular groups, such as 200 every Monday. Moving up only matters if the front of the line actually gets access.
• How fake signups are handled. Kite writes rules that keep the line honest, such as one place per confirmed email address, no credit for referring yourself, and treating variations of one address as the same person.

Kite keeps the agreed rules in your knowledge base, so the spec, the page, and every email describe the same waitlist.

Tell them exactly what the waitlist does from the user's side and what information it has to keep, and Kite writes that down as a spec. The spec turns the agreed design into something an engineer can estimate and build without having to guess what marketing meant. It usually covers:

• The flow, screen by screen. The signup form, the email confirmation, the status page with the person's place in line and personal link, the sharing options, and the moment someone learns they're in.
• The information each signup needs. The person's email address, when they joined, their personal referral code, who invited them, whether they've confirmed their email, and their current place in line.
• The rules for moving up, with worked examples. Each rule is written as a plain sentence and followed by an example, so your engineers and your team agree on what happens when two people tie or a friend never confirms their email.
• The emails and when each one sends. The welcome email with the personal link, the note when someone moves up, the message when they reach a milestone, and the email that tells them their access is ready. Kite writes the copy for each one in your brand voice.
• The events to record. Signing up, confirming, sharing, a friend joining through an invite, being let in, and first using the product. These are what Kite uses later to measure how the waitlist grows.
• The rules against fake signups. How the product checks for duplicate and self-referred signups, and what happens to a place in line that turns out to be fake.
• What your team needs to run it. A way to see the list, let in the next group, and remove signups that break the rules.
• The checks before launch. A short list your team can run through to confirm the waitlist behaves the way the spec says.

The referral features live inside your product, so your engineers build them. If your product code is in a GitHub repository you've connected, Kite can open the spec as a GitHub issue so it lands in the queue your engineers already work from. Otherwise, you can paste it into whatever tracker your team uses. When an engineer has a question about a rule, they can ask Kite directly, and Kite answers from the same design it wrote the spec from.

The waitlist page has one job, which is getting the right visitors to leave their email address. Kite writes and builds it in your brand's voice and visual style. A typical page names what early access gets you, describes the product in a sentence a friend would understand, asks only for an email address, and explains how inviting friends moves you up.

If Kite hosts your website, it adds the page there and gives you the live link after you approve it. It can also send each signup from the page to your connected Mailchimp audience with the tags you choose, so the list is ready for your launch emails. If your site runs on Webflow, Kite adds the page's content to your Webflow CMS through your connected account and publishes the site. When the signup form lives inside your product instead, Kite puts the page copy in the spec for your engineers.

People share more when the message is already written for them. Kite writes a short note for text or email, versions for LinkedIn and X, and an image sized for each. Here's a note Kite might write for a project-management tool for design agencies:

I just joined the waitlist for Framewell, a project tool built for design studios. It tracks client feedback on every file so nothing gets lost in email. If you sign up with my link, we both move up the line.

These messages go on the status page and in the welcome email, so people can copy them the moment they sign up.

A referral waitlist needs a first group of people before invites can do any work. Kite drafts the announcement that brings them in. That might be a launch post for your company and founder accounts, an email to your existing contacts or newsletter, and posts for the communities where your buyers already talk. Kite researches public conversations on X and Hacker News to find where people are already discussing the problem your product solves.

For a product sold to businesses, Kite can also build a list of people who match your ideal customer and write a personal invitation to each one. You approve the posts, the announcement email, and the invitations before Kite publishes or sends them.

Kite measures whether the waitlist is growing on its own or only from the people you bring in yourself. The most useful number is how many new signups each group of signups brings in. If every ten people who join bring in four friends, a fair share of your list is coming from invites rather than from your own promotion. Kite also tracks:

• how many signups come from invites compared with your own announcements
• what share of signups send at least one invite
• how many invited friends sign up and confirm their email
• how many people you let in actually start using the product

Kite reads the page's visits and form submissions from its built-in analytics when it hosts your site. For the events inside your product, it uses the events named in the spec. When your product sends those events to PostHog, Kite builds the funnel from signup to first use and reports each step.

Those numbers tell Kite what to change. If lots of people sign up but few share, the status page may be hard to find, or the first milestone may feel too far away. If plenty of people share but few friends join, the share message may not explain the product clearly. Kite suggests the change, explains why, and records what it learns in your knowledge base so the next adjustment builds on the last one.