Why we built our patient network on UNA

Calling any platform "the best" is an invitation to argue. If you mainly publish articles, WordPress is stronger. If you never want to touch a server, a fully hosted community product is easier. But when the community itself is the product, not a website with comments bolted on, UNA makes an unusually strong case. A few things that mattered for us:

  • It's built around members, not pages. Profiles, groups, spaces, events, messages, notifications and moderation share one system, so a member has one identity and one set of privacy rules wherever they are on the network.
  • It grows with you. We started with profiles and two private spaces. Since then we've added events and a resource library without migrating anywhere. Studio handles most of the configuration, and a developer can go further with custom modules or the API.
  • The permissions are granular. Membership levels and per-space privacy let us keep some groups invite-only and others open to anyone searching for help at two in the morning.

Ownership is the strategic part. The code is open source and runs on our own servers. For a patient community that isn't a nice extra. Our members' conversations, and the policies that govern them, stay with us rather than with a vendor whose priorities could change next year.

It isn't effortless. Someone has to keep the server patched and the backups tested, and I lean on more technical volunteers for that. But I'd rather carry that work than tell a caregiver their support group has moved because a pricing page changed.

  • 1
  • 😆 1
  • 54

Comments

    • One caveat I left out: if nobody on your team is comfortable with servers, budget for help with hosting and updates before you launch, not after.

      Login or Join to comment.