Setting up your YeahApp account — best practices

This guide covers the two situations we see most often:

1. Large, established organisations — clubs, federations, chambers of commerce, alumni associations, professional bodies
2. Founders and small startups — one or two people building a new community from scratch

The one rule that drives everything

YeahApp accounts represent real humans, not organisations. There's no "company account" type — every account is a person who can log in, with a name, an email, and (when payments are involved) a verified identity on file with Stripe.

This matters because of a process called KYC (Know Your Customer). When your community starts taking payments — ticket sales, membership dues, event fees — Stripe is legally required to verify a real human is behind the account. That human provides ID, proof of address, and sometimes business documents. Once verified, the Stripe relationship is tied to that specific person, not to the email address they used to sign up.

So when you set up your account, you're really making two separate choices:

• Which inbox the account uses for login and notifications (easy to change later — same account, just edit the email field)
• Which human is on file for Stripe and legal purposes (substantive, hard to change)
• What kind of entity that human is verifying on behalf of — themselves as an individual, a registered company, or a non-profit organisation (chosen at Stripe onboarding, hard to change after the fact)

Keep these three separate in your head and the rest of this guide makes sense.

If you're a large established organisation

You almost certainly want one role-based email + one designated human behind it.

Pick the email first. Use a generic, organisation-owned address like admin@yourbody.org, events@yourchapter.com, or members@yourassociation.eu. Do not use someone's personal Gmail. The whole point is that this address survives staff turnover.

Pick the human second, and pick deliberately. This person:

• Provides ID for Stripe KYC during onboarding
• Receives all platform notifications (sent to the role inbox, which forwards to them)
• Is the formal account owner in YeahApp
• Should be your operations or finance lead — the person likeliest to still be there in two years

Common mistake: picking the most enthusiastic volunteer instead of the most stable employee. Enthusiasm fades; treasurers stick around.

Then invite everyone else as themselves. Once the role account is set up and your community is created, go to Members and invite your other admins using their personal accounts and personal email addresses. Give them the Admin role. They'll do the day-to-day work — managing events, posting updates, approving members — and their actions will be properly attributed to them as individuals. The role account just sits there holding ownership.

One more important choice — Stripe entity type. When your role-account human goes through Stripe Connect onboarding to enable payouts, Stripe will ask whether they're verifying as an Individual, a Company, or a Non-profit. For an established organisation, pick Company or Non-profit, not Individual. This is the difference between "the Stripe relationship is bound to one human's personal ID" (Individual) and "the Stripe relationship is bound to the organisation, with a designated human as its representative" (Company / Non-profit).

Why it matters: when leadership rotates — new president, new treasurer, new committee — a Company / Non-profit Stripe account just needs the listed representative updated via a Stripe form. An Individual account requires creating a brand-new Stripe Connect account from scratch and re-onboarding, which interrupts payouts. Pick the right entity type once at the start and you avoid this entirely.

Don't share the role account password. The role inbox is a forwarding alias to the responsible human. It is not a shared login that several admins all use. If multiple people need to log in as that account "to handle things," you've created an audit trail where nobody knows who actually did what. Each admin gets their own personal account.

If you're a founder or small startup

You don't need to overthink this on day one. Use your personal email, sign up, create the community, get going. For a small founder-led community, the human and the organisation are basically the same thing, and there's no pressing need to separate them.

The thing to do later, once your community shows signs of staying power (you've crossed your first hundred members, you're collecting recurring dues, or you've brought on a co-organiser):

1. Go to your account settings and change your email from you@gmail.com to a role address like admin@yourcommunity.org. From that moment on, you'll log in with the new email and password resets and platform notices go to the new address. The account record itself doesn't change — same Stripe verification, same activity history, same community ownership — only the email field on the account is replaced.
2. Set up forwarding so the role address still lands in your personal inbox.
3. Carry on.

You've now turned your personal-style account into an organisation-style account without disturbing anything underneath. When you eventually hand the community to someone else, that role inbox is ready to forward to them instead.

What you can't avoid (for individual accounts): If you onboarded Stripe as an Individual and a different human eventually takes over the community, Stripe will need to set up a brand-new Connect account and re-run KYC on the new person. That's a Stripe rule, not a YeahApp limitation — the verification is bound to a specific human's identity, and there's no way to "transfer" an Individual account to a different person.

If you onboarded as a Company or Non-profit, leadership change is much smoother — you update the listed representative on the existing Stripe account via a form, no re-onboarding needed. This is one of the main reasons established orgs should pick Company or Non-profit at Stripe onboarding, not Individual.

A quick decision tree

Using the role email account to join other communities. The role account represents your organisation as the owner of its own community. If you log in as admin@acme.org and join three other communities as a member, your activity (comments, RSVPs, applications) gets attributed to a faceless role address that may outlive whoever actually did it. Use your personal account when participating elsewhere; reserve the role account for operating your own community.

Multiple people sharing the role account login. This breaks audit trails and is a security weak point. The role account has one human behind it. Other admins use their own accounts.

Picking the wrong human for Stripe KYC. Whoever does the verification is on the hook with Stripe for everything that flows through the account. Pick someone with a stable role in the organisation, ideally with finance or operations responsibility, not the volunteer who just happens to be most available that week.

Onboarding Stripe as Individual when you're a registered organisation. This is the single most common — and most painful — mistake. If your organisation has any legal entity status (vereniging, foundation, registered charity, ltd, association, federation), pick Company or Non-profit at Stripe Connect onboarding. Going through Individual KYC binds the Stripe relationship to one human's personal ID, which means leadership change later requires a brand-new Stripe account from scratch. Picking the right entity type once at onboarding is the difference between "the new treasurer fills in a Stripe form" and "we lose two weeks of payouts while re-onboarding."

Treating "change email" and "change owner" as the same thing. They aren't. Editing the email on an existing account is a five-second cosmetic change. Transferring ownership to a different human triggers Stripe re-onboarding and is a real piece of work. Plan accordingly.