Before You Add a Fourth Friend to the Repo: The 12-Point Onboarding Checklist for Group Sites

Every friend-built website hits the same moment eventually. The project is humming along, the group chat is settled into its rhythms, and then someone says the thing: "You know who would be great at this?"

And suddenly you're onboarding a new collaborator into a project that was never designed to have one.

Here's the truth nobody says out loud: most group sites don't die from arguments or abandonment. They die from bad handoffs. A new person joins, hits a wall of undocumented weirdness, feels like an outsider for six weeks, and quietly drifts away. Or worse — they dive in, break an unwritten rule nobody told them about, and the vibe curdles.

Growth doesn't have to break the vibe. But it does require planning. Here's the twelve-point checklist to run through before the invite goes out.

1. Write Down the Unwritten Rules

Every friend project has them. The deploy happens on Sundays because Dave's on call Mondays. The newsletter voice is "helpful Midwestern neighbor," never "hustle bro." Nobody touches the homepage collage without a vote.

These conventions live in group chat history and shared memory — which means they're invisible to anyone new. Spend one evening writing them down. Call it a style guide, a wiki page, a README with feelings. Doesn't matter what you name it. What matters is that your new member stops feeling like they're guessing at a secret test.

2. Decide Who Has Keys Before They Arrive

Admin access is where friendships go to get complicated. Before day one, agree on exactly what the new person can touch: Can they deploy? Do they get domain registrar access (hard no, at least initially)? Can they invite others?

Write it down, tell them directly, and revisit it in ninety days. "We'll expand your access as we go" feels like trust. "You have root and we didn't discuss it" feels like an accident waiting for a Saturday.

3. Give Them a Stupid First Task

The first joint commit should feel good, not terrifying. Skip anything touching production. Give them something small, visible, and genuinely theirs: fix the broken link in the footer, add their bio to the About page, pick the next poll topic.

The goal is a merged pull request within the first week. That tiny green checkmark does more for belonging than any welcome message.

4. Assign a Buddy, Not a Boss

Pick one existing member to be the go-to for questions — the person who explains why the staging server is named after a cat. This isn't a management role. It's a "you can ask me the dumb questions" role. New members burn out fastest when they feel like every question is an imposition.

5. Audit the Docs (Or Admit There Are None)

Open your project like a stranger would. Is the deployment process written anywhere? Do passwords live in one person's head? Is there a note somewhere about why you're still on that one weird hosting plan?

If the answer to any of these is "ask Tom," you've found your pre-boarding homework.

6. Set the Money Expectations Early

Server bills, domain renewals, the occasional stock photo subscription — new members deserve to know the financial shape of the thing before they're in it. Is it split evenly? Is it "buy a round sometime"? Is one friend quietly eating the costs?

Money conversations get harder the longer they're delayed. Have the awkward one first.

7. Explain the Decision-Making Process — Actually Explain It

Is it consensus? Majority vote? "Whoever cares most wins"? Every group has a system, even if it's unspoken. Say it out loud to the new member, including its flaws. "We usually just vibe-check big changes in the chat, but you can call a vote if you want" is a perfectly legitimate constitution.

8. Introduce Them Like a Human, Not a Resource

When they join, write a real intro in the chat or on the site: who they are, what they're into, why you asked them. Not "adding @jess to the repo." People commit to people, not contributor numbers.

9. Show Them Where the Bodies Are Buried

Every project has landmines. The client who still emails the old address. The page that breaks if you update that one plugin. The domain that expires in March and always causes a panic. A fifteen-minute walkthrough of known hazards saves a future blowup — and signals that you trust them with the real story.

10. Agree on Response-Time Reality

Friend projects run on asynchronous energy. Some members check in daily; some resurface monthly with a burst of great work. Tell the new person which rhythm is normal so they don't interpret silence as hostility — and so their silence isn't misread either.

11. Make a 90-Day Check-In Date

Put it on the calendar now. Three weeks in, ask: "Is this what you expected? Are we giving you enough to do? Too much?" Most quiet departures are preventable with one honest conversation at the right time.

12. Let Them Change Something

Here's the one that separates welcoming groups from museums of past glory. If the new member can't alter anything — a design choice, a process, a section of the site — they're not a collaborator. They're an audience.

New blood that can't leave a fingerprint always leaves eventually. Let them repaint a wall.

The Bottom Line

The best friend-built sites aren't frozen in amber from the day they launched. They're alive, and living things grow. Onboarding a new member well is how a project goes from "the thing my friends and I made" to "the thing we're all making" — which is, honestly, the whole point of building things on the internet together.

Run the checklist. Send the invite. Save a seat at the welcome wagon.