A club or member organization usually outgrows its first website in the same way. The content is spread across a wiki, a shared drive and someone’s inbox, and only one or two people know how to change anything. A member database website fixes that by giving each person a login and a role, so members can add things, trusted people can check them, and the public sees only what it should. The build is the easy part. The hard part is deciding who can do what, and that’s best settled before anyone writes code.
Logins: who can get an account
There are three common setups:
- Invite only. An admin adds each member by email. Simple and tight, and a good fit for a small club with a fixed roster.
- Open sign-up with approval. Anyone can request an account, and it waits until an admin confirms the person is a member. A good fit for groups with steady turnover, like student clubs.
- Open sign-up. Anyone can join right away. This is rarely right when members can post content.
Whichever you choose, accounts belong to people, not positions. The treasurer signs in as themselves with an admin role, rather than everyone sharing a “treasurer” login. When the treasurer changes, you move the role to the new person instead of passing around a password.
Roles: what each person can do
Keep the list short. A typical set for a club that keeps records, articles or event results:
| Role | What they can do |
|---|---|
| Visitor (not signed in) | Read public pages |
| Member | Read members-only pages, submit new entries, edit their own drafts |
| Editor | Edit any entry and fix formatting, but not approve |
| Approver | Approve or reject entries waiting in the queue |
| Admin | Everything above, plus manage accounts and roles |
Some clubs merge editor and approver into one role. That works as long as more than one person can approve, so the queue doesn’t stall when one officer is busy or away. Write each role down in plain words before the build starts. If two officers describe the same role differently, settle it now rather than after members are using the site.
How the approval queue works
When a member submits something, such as a race result, an article or a directory listing, it goes into a queue marked pending. It isn’t public yet. Approvers see the queue, open each entry, and approve it, reject it with a note, or send it back for changes. The member hears back either way. An alert to approvers when something new arrives keeps entries from sitting for weeks.
Every action gets logged: who submitted, who approved and when. When someone asks months later why an entry says what it says, the log answers the question without anyone digging through email.
What happens when an approved entry is edited
This is the rule clubs most often forget to decide. If a member can edit an entry after it’s approved, the approval no longer covers what’s on the page. So an edit to an approved entry sends it back to the queue for approval.
There are two ways to handle the page while the edit waits:
- Keep the last approved version public, and show the edit only to approvers until it’s approved. Visitors never see unchecked changes, and the page never disappears.
- Hide the entry until the edit is approved. This is simpler to build, but a one-word typo fix can take a page offline for days.
We usually recommend the first. Either way, keep a version history so an approver can see exactly what changed and roll back if needed.
Member privacy
A member database holds personal details, so decide early what each audience can see:
- Never show members’ email addresses on public pages. They get collected by bots and flooded with spam. Use a contact form that forwards messages, or show addresses only to signed-in members who opted in.
- Show display names publicly, if anything. Some members will want initials only.
- Let members control their own profile fields, such as phone, address and photo.
- Collect only what the club uses. If nobody ever looks at members’ birthdays, don’t ask for them.
- Decide what happens when someone leaves. A common approach: deactivate the account, keep past entries under their name or “former member,” and delete personal details on request.
Demo access for reviewers
Before real members are invited, the people approving the build need to see it from every side. We create a demo account for each role (demo member, demo editor, demo admin) and fill the site with test entries, so reviewers can submit, approve and reject without touching real data. The demo accounts are removed before the site goes live.
If you’re moving off an old system, the same care applies in the other direction. While we explore an old wiki or members area, we never press “forgot password” (it can reset an officer’s login or send email to the whole list) or any delete button. Old page addresses, like a wiki’s doku.php?id= links, get 301 redirects to the matching new pages, so old links and bookmarks keep working. Our guide to moving an old club wiki goes through that move in more detail.
What to decide before the build
Here’s a one-page list your board can agree on before any work starts:
- Who can get an account, and who approves new accounts
- The roles, in plain words, and who holds each one today
- What needs approval and what doesn’t (an editor’s typo fix might not)
- At least two people who can approve
- What’s public, what’s members-only and what’s admin-only
- Which member details you collect, and who can see each one
- What happens when a member leaves, and when officers change at the end of a term
- Who owns the admin account and the domain: the club, through a shared officer email, not one person’s personal address
Item 8 matters more than it looks. Officers turn over, and a site whose only admin login belongs to someone who graduated or moved away is a site nobody can change. More on what we build for groups like yours is on our clubs and organizations page.
Next step
Bring that list to us, even half filled in. We’ll turn it into a plan for logins, roles and the approval flow, and tell you what the build involves. Get in touch through our contact page, or read about our custom web apps and member databases. If you want to see the full picture for member groups first, start with the clubs and organizations overview.