# Core concepts > Workspaces, projects, forms, pages, contacts and submissions: what each one is, and why the model is shaped this way. Source: https://getlaunchlist.com/help/docs/getting-started/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. ```text 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. > [!NOTE] Status, stage and trust are three different questions > **Deliverability** asks "can this address receive mail?". **Stage** asks "where are they in my > funnel?". **Trust** asks "is this a real person?". They move independently, and merging any two of > them is how waitlist tools end up unable to answer any of the three. ## 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}`](/help/docs/api/contacts-update) or an automation. > [!NOTE] Alpha and beta cohorts are tags, not stages > A stage holds one answer: somebody is in exactly one at a time. "In the beta", "wave 3" and > "design partner" are not like that: a beta tester can also be a paying customer. Use tags and > segments for those, and keep stages for the one-way journey. ## 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](/help/docs/getting-started/quickstart): put this to work in five minutes - [How referrals work](/help/docs/referrals/how-it-works) - [The REST API](/help/docs/api/contacts-create), which exposes these same objects ## Common questions ### What is the difference between a project and a workspace in LaunchList? A workspace is your account and the thing that gets billed; a project is one product or launch inside it. Teammates are invited to a workspace, and every form, page and contact belongs to a project inside that workspace. ### What is the difference between a contact and a submission? A submission is one form fill, kept forever exactly as it arrived. A contact is the deduplicated person those submissions belong to. Somebody who signs up three times is three submissions and one contact. ### Can I run more than one waitlist in one account? Yes. Create a project per product or launch. They share billing and your team, but their audiences, forms, pages and referral leaderboards are completely separate.