Core concepts

Six ideas cover almost everything in LaunchList. This page explains what each one is and, where it matters, why it works the way it does.

Workspace                what gets billed, and who your teammates are
  └─ Project             one product or launch
       ├─ Form           the fields people fill in
       ├─ Page           the hosted launch page
       └─ Contact        a person on the list
            └─ Submission   one form fill, kept forever

Workspace#

Your account. It holds the subscription, the team, and one or more projects.

Signing up creates a personal workspace of one automatically, so if you are a solo founder you will never see team UI. Agencies and teams invite people into a workspace and assign roles.

Billing is per workspace, not per project or per person. Every project shares the workspace's plan, and contacts are counted across all of them together.

Project#

One product, or one launch. It owns everything a launch needs: forms, pages, contacts, referral leaderboard, email campaigns, analytics.

Projects are fully isolated from each other. The same email address signing up to two of your projects is two separate contacts with two separate referral codes and two separate positions, because they are two separate waitlists.

Use one project per thing people can join. Do not use projects as folders.

Free includes 1 project, Collect 3, Launch 10 and Grow unlimited. When a launch is finished, archive its project: it stops counting toward the limit and its contacts stop counting toward your plan size.

Form#

The fields someone fills in. A project can have several: a hero form, a footer form, a survey after launch.

The important idea is that a form is a schema, not markup. You define fields once and every surface renders them: the hosted page, every embed on every site, the popup, the API. Change a field and all of them update, with nothing to re-paste.

Identity is generic. Most waitlists use email, but a form can identify people by phone, by username, by wallet address, by a custom scalar of your own, or by nothing at all. There is no hardcoded assumption that a signup has an email address, which matters for products where it genuinely does not.

Page#

The hosted launch page, built in a visual editor. It is server-rendered, so search engines see real HTML rather than an empty shell, and on Collect, Launch and Grow a page on your own domain can be indexed.

A project has one launch page today. The model already allows several (variants for an A/B test, one per campaign, one per connected custom domain), and that is coming, but it is not switched on yet. Most launches only ever need the one.

Contact#

A deduplicated person in your audience. This is the object almost everything else hangs off.

A contact carries four independent things, and keeping them separate is what stops the model collapsing into a mess:

• Identity: the identifier and its type (email, phone, username, wallet, a custom scalar, or none at all)
• Deliverability: whether we can actually reach them
• Stage: where they are in your funnel, which you configure
• Groupings: segments and tags

Plus the referral data: their code, who referred them, how many people they have brought in.

Submission#

One form fill, stored exactly as it arrived, forever. Submissions are append-only: they are never edited and never rewritten.

Many submissions collapse onto one contact. Somebody who signs up, comes back through a referral link, and later answers a survey is three submissions and one contact.

This split is why editing a contact never loses the original answers, and why you can always see what somebody actually typed.

Pipeline stages#

Your funnel, and you configure it from Audience → Signups: press Customize stages, the small icon at the end of the pipeline strip above the table. The default is waitlist → invited → joined → converted, plus a terminal declined for people you review and do not admit. Rename them, recolor them, reorder them, and add stages of your own.

Three of them are wired to things that have to keep working, so they can be renamed but not removed: signups always land in the first stage, inviting somebody always moves them to the invited stage, and redeeming a code always lands them in the joined stage. Everything else, including converted and declined, is yours to remove.

Removing a stage always asks where the people standing in it should go. Nobody is ever deleted with a stage. If there are a lot of them the move runs in the background and shows you its progress, so a big audience never blocks the page or times out.

Moving people between stages is how you run an invite wave: filter to the people you want, invite them, and let an automation email them.

converted is the one stage nothing sets for you, on purpose. Whether somebody became a customer is a fact inside your product, not ours, so you tell us, with PATCH /v1/contacts/{id} or an automation.

Segments and tags#

Tags are manual labels you apply.

Segments are saved filters. A dynamic segment re-evaluates itself, so "people who referred at least three others and have not been invited yet" stays accurate as your audience changes. A static segment is a frozen snapshot.

Use segments to decide who gets an email, who gets invited, and who to look at.

Events#

Everything meaningful that happens emits an event: a signup created, a contact verified, a referral made, a trust verdict changing. Events are what your webhooks and automations react to.

You rarely think about events directly. They matter because they are the reason a new integration never requires changing anything that already works.

Next#

• Quickstart: put this to work in five minutes
• How referrals work
• The REST API, which exposes these same objects