Tunet - White-Label Community Platform for Membership Organisations
Member Community Platform for a Norwegian Software Company
Designed and built a clickable community admin console for an Oslo software company's white-label community platform, shown for its first customer, a national hiking association: a community overview, a moderation queue with a full case workspace and decision flow, and event management with RSVPs, waitlist, check-in and attendee messages.
Most of our work is under NDA. Per agreement, we can share the work but not the company details - all names and identifying information shown here have been changed.
Impact
Community overview, moderation queue, case workspace with decision and escalation, events list and event management with details, attendees, waitlist, check-in and messages tabs.
From no action to removal, warning, mute, suspension from a space or the community, and ban. Each decision names a guideline rule and sends a pre-filled, editable statement of reasons.
Urgent cases are due in 4 hours and normal ones in 24. Each case shows its age against the target, and overdue cases are flagged red in the queue and on the overview.
14 moderation cases across 8 reasons, 17 events, 14 spaces, 14 members and 30 RSVPs on one full event, 24 going and 6 on the waitlist.
The Problem
Høgfjellslaget, a national hiking association with around 38,000 members and 40 local chapters, ran hikes, cabin work weekends and courses through Facebook groups, email lists, a spreadsheet per chapter and a website form. Members off Facebook missed trips, popular trips were overbooked with no fair waitlist, nobody knew who was at the meeting point, and the association had no control over moderation or its own members' data.
Our Solution
Tunet gives each membership organisation its own branded community, with spaces, posts, events and messages for members and a console for admins. The demo shows the admin side for Høgfjellslaget: an overview of what needs attention, a moderation workspace that decides each case with a rule and a statement of reasons, and event management that runs RSVPs, the waitlist and check-in in one place.
The Challenge: A Community the Organisation Owns
Bråtebakken Labs sells Tunet to membership organisations that want their own member community instead of a Facebook group. Each one is a separate tenant with its own branding, rules, members and data, run largely by volunteers.
Member Life Spread Across Channels
Sign-ups came in through Facebook, email and a website form, so chapter leaders could not see who was coming. Trips were overbooked, there was no fair waitlist, and no record of who actually turned up.
Volunteers Facing Serious Content
Most moderators are volunteers, but reports can include threats, doxxing or worse. Suspected child sexual abuse material and credible threats must go to Bråtebakken's trust and safety team, and members whose content is removed are owed a reason and an appeal, following Digital Services Act patterns.
Whose Data Is It
Each organisation is the controller for its members' data under the GDPR and Norway's Personal Data Act, with Bråtebakken as its processor. Members need self-service download and deletion, sign-up stops under the tenant's minimum age of 13 or higher, and sponsor messages need a separate opt-in under the Marketing Control Act.
One Product, Many Organisations
Every tenant brings its own logo, colours and domain, and branding must pass a WCAG 2.1 AA contrast check before it is published. Some organisations reveal sensitive data through membership alone, so a tenant can hide member lists and public spaces.
Our Approach: From Community Rules to a Clickable Console
Spec and Rules Research
Mapped 8 roles, from member and space host to community owner and Bråtebakken platform operator, and 45 screens across the member app, the community admin console and the operator view. Defined the data model for tenants, spaces, posts, events, RSVPs, moderation cases, sanctions, data requests and the audit log, and wrote down the rules the design follows: GDPR and the Personal Data Act, Digital Services Act patterns, the Marketing Control Act, consent for images of people and Norway's universal design rules.
Clickable Demo on a Production UI Kit
Built the admin console's 5 key screens on a production dashboard kit for Høgfjellslaget: the overview with KPIs, needs attention, plan usage and activity charts, the moderation queue and case workspace with decision and escalation modals, the events list with a new event form, and event management with capacity changes, waitlist offers, manual check-in and attendee messages. All actions run on local state.
What a Production Build Adds
The member app for web, iOS and Android, sign-in by magic link, Vipps Login, Apple and Google, push, email and SMS delivery, image storage in the EEA with PhotoDNA hash matching and an image classifier, search, real-time updates, Kartverket maps, MET Norway weather and calendar feeds. Plus the remaining admin screens, the platform operator view with Stripe billing, role-based permissions and an append-only audit log.
Why It Works: Clear Rules for Volunteer Teams
Every Case in One Workspace
The queue and the case sit side by side. A moderator sees the content as the member saw it, the surrounding thread, previous versions, the reports, auto-filter matches with their score and the author's history, with private notes that the author and reporters never see.
Decisions That Explain Themselves
Each decision pairs an action with a guideline rule and a pre-filled statement of reasons for the author, while reporters get the outcome only. Sexual content stays blurred until a moderator opens it, and an Escalate button hands a case to Bråtebakken with a category and note.
Fair Waitlists by Default
Full events take a waitlist with auto-promotion and a 24-hour hold on offered spots. Raising capacity promotes from the waitlist, and closing check-in marks the rest as no-shows, so the attendance rate compares checked in with going.
The Overview Shows What Is Waiting
Admins open on a list of what needs them: cases past target, join requests waiting over 48 hours, events with a waitlist but no host confirmation, failed member imports and data requests near their due date, next to plan usage against the member limit.
Related case studies
View all: Social & community
Fernlight - Safety-First Dating App with a Trust and Safety Console
Designed and built a clickable trust and safety console for a Wellington start-up's dating app for adults in New Zealand and Australia: a report queue triaged by severity with response targets, a case workspace that shows only reported conversations, romance scam clusters and a support inbox that hands safety issues to the queue.
Hengert - Trust and Safety Console for an End-to-End Encrypted Messenger
Designed and built a clickable operator console for a Zurich company's end-to-end encrypted messenger for families and small groups: an abuse report queue worked only from content users chose to forward, account pages that list what the server holds and what it does not, and a law enforcement desk that answers only with data that exists.
Enterprise Software Engineering - Human + AI
Contact Us
© 2026 - Copyright. All Rights reserved Oceanlab
Location
Global Headquarters
21 Merchant Road, 3rd Floor, Singapore 058267
Main corporate office and leadership operations
North America Office
548 Market Street, PMB 12345, San Francisco, CA 94104
Client operations and business development
India Office
402 Shivalik Shilp II, SG Highway, Ahmedabad 380015
Engineering and delivery center
Enterprise Software Engineering - Human + AI
Contact Us
Locations
Global Headquarters
21 Merchant Road, 3rd Floor, Singapore 058267
Main corporate office and leadership operations
North America Office
548 Market Street, PMB 12345, San Francisco, CA 94104
Client operations and business development
India Office
402 Shivalik Shilp II, SG Highway, Ahmedabad 380015
Engineering and delivery center
© 2026 - Copyright. All Rights reserved Oceanlab