Clubs and organizations often run on a website someone built years ago: an old wiki, a forum, a shared spreadsheet for logs, and one volunteer who knows how it all fits together. It works until that volunteer graduates or moves on. A member website puts it all in one place that the next group of officers can run.
Who this is for
- Hobby and gaming clubs with logs, rules wikis, rosters and approvals.
- Student organizations that hand the site to new officers every year.
- Associations and nonprofits with member directories, events and document libraries.
- Any group where some content is public, some is for members only, and some needs someone’s approval before it counts.
What we build
- A welcome in your own words: what the club is, who it is for, and how to join, written so a newcomer gets it on the first visit.
- How it works: how to join, how to take part, when and where things happen. New members should not have to ask.
- Member logins with roles: member, editor, approver, admin, or whatever your organization calls them.
- Approval queues: new entries and edits wait for the right person before they go public. Editing an approved entry sends it back to the queue, so nothing changes without review.
- A searchable archive: game logs, meeting notes or records with search and filters, instead of a folder of files.
- A wiki or library for rules, guides and reference material, moved from your old wiki with its history kept where possible.
- An admin area for officers to manage members and roles.
- Demo access codes so reviewers can try the site as each role before launch.
Our guide to member roles and approvals covers the decisions to make before a build like this.
Moving from the old site without losing anything
The rebuild has to do everything the old site did. So we start with an inventory of every page, feature, form, report and admin action, and the new site must cover each one or list it as dropped with a reason you agreed to.
We explore the old system read-only. On one old club system, pressing “forgot password” deleted accounts, so we never press “forgot password”, delete, save, approve or settings buttons on a system we are only looking at. Every old address, including the odd ones like doku.php?id= links from a DokuWiki, is mapped to its new page and redirected. Our guide to moving an old club wiki walks through the steps.
Keeping the content does not mean keeping the look. The new design is built for the club as it is now, on phones as well as computers.
Privacy
Old club sites often show members’ emails and phone numbers to anyone. The rebuild does not. Contact details are visible only to the people who need them, and the privacy policy says who can see what.
Built to outlast the current officers
The site runs on Wix’s backend, with members, logins and data in Wix’s cloud, and our custom code for the screens. That means no server in someone’s dorm room, and a dashboard the next officers can use. With managed hosting, we handle the technical side and the role changes each year, so a handover is a short checklist, not a crisis.
Accessible to every member
Members use the site on phones, old laptops, with screen readers and zoomed in. We build to WCAG 2.2 AA and check every page at nine screen sizes. See accessibility maintenance for what that covers.
Where to start
Send us the address of the current site and a short list of what members and officers complain about. For the app side of the work, see custom web apps and member databases, and for budgets, the cost guide.
