Nine questions to ask a community platform before you move your members
Comparison pages in this category are written to produce a tie. Everyone has a feed, courses, events, a member directory and payments. The grid fills with green ticks and tells you nothing, which is the point of the grid.
The differences that will actually affect you show up six months in, usually on a bad day. These are the questions that surface them early. I have tried to write them so you can ask a vendor directly, and I have included what a weak answer sounds like — including for us.
1. "When a member's payment fails, what happens, and when?"
You are testing whether payment and access are the same system or two systems held together by a webhook and optimism.
A good answer names a state — past due, suspended — describes what the member sees, and says whether they lose access immediately or after a grace period. A weak answer is "Stripe handles that". Stripe handles the charge. Stripe does not know what a channel is.
Ask the mirror-image question too: when they pay again, how fast do they get back in? Recovery paths are less tested than removal paths, everywhere.
2. "Show me the URL of a locked piece of content."
This is the sharpest question on the list and it takes ten seconds to fail.
Ask for a link to a paid course or a private channel, then open it signed out, or signed in as a free member. If you get the content, their access control is a hidden button. If you get a 404 or a lock screen, ask the follow-up: is that enforced in the database, or in the page?
The distinction is not academic. A platform that enforces access when rendering a page will eventually ship a new page — a search result, an RSS feed, an API endpoint, a mobile app — that forgets to. The leaks in this category are almost never a broken lock; they are a second door somebody added later.
For what it is worth, our own answer: access is decided by row-level security and by the functions that read on your behalf, so a gated item returns nothing rather than returning something the page is trusted to hide. Where we sequence courses, there is a database trigger that refuses the enrolment outright as a last line. The lock screen the browser draws is the last layer, not the first.
3. "What does a member see when they hit something they cannot access?"
Different question from the last one, and it is about product rather than security.
The default in most software is a 403, a redirect to a pricing page, or — worst — the item silently not existing, so the member never learns there is more. All three are decisions somebody made by not making one.
What you want is a lock screen that says what this is, why it is locked, and exactly what to do next, with a working button. And you want to be able to edit that copy per item, because "upgrade to Pro" and "this channel is for the Tuesday cohort, ask Maya" are different situations.
While you are there, ask what happens on the item that has no path forward — the private channel a member can only be invited to. If the answer is a button that does nothing, or a button that files a request nobody ever sees, that is worth knowing. (We shipped exactly that mistake: a request-access flow where the notification pointed at a page that had no approvals surface on it. It took an outside reviewer to notice, because every test passed.)
4. "How do I get my data out — and what shape is it in?"
Everyone says "you can export". Push on the shape:
- Members with their email addresses, or a member list with the emails stripped?
- Posts and comments with their threading and authorship, or a flat CSV?
- Course structure and per-member progress?
- Uploaded files, or links to files that stop resolving the day you cancel?
The last one is the killer. A media export that is a list of signed URLs is not an export, it is a countdown.
You are not asking because you plan to leave. You are asking because the answer tells you how the vendor thinks about who owns the community.
5. "What is your pricing model, and what happens to it if I get big?"
Three models exist, and they fail differently:
| Model | Fails when |
|---|---|
| Percentage of your revenue | You succeed. It scales with your income and you cannot negotiate it. |
| Per-member pricing | You grow a free tier, or run a large low-revenue community. |
| Flat subscription | You are tiny — you pay the same as someone ten times your size. |
None is dishonest. But know which one you are buying, and specifically ask whether a percentage applies on every plan or only on the cheap ones, because "0% transaction fees" on the enterprise tier and 5% on the starter tier is a common and rarely highlighted shape.
We charge a flat monthly fee and take 0% on every tier, which means we are the worst-value option for a community with ten members and the best-value one for a community with a thousand. That is the trade; I would rather state it than let you discover it.
6. "Who moderates, and what can they actually do?"
Ask for the list of roles, then ask what each one can do that the others cannot.
The specific failure to probe for: a "moderator" role that grants access to an admin page which then refuses every action on it. This is extremely common, because permission systems get built as a list of checkboxes and the checkboxes get added faster than the enforcement behind them.
We shipped that too, and the fix is worth stealing as a question: we removed three moderator permissions — schedule, workflows and landing pages — because each one unlocked a route that then 404'd. A permission that grants a door and not a room is worse than no permission at all, because now somebody thinks they can help.
7. "What runs on a schedule, and how do you know it ran?"
Deceptively boring, extremely diagnostic. Community platforms are full of things that must happen on time: digest emails, drip lesson releases, event reminders, waitlist promotions, dunning, scheduled posts.
Every one of those is a background job, and background jobs fail silently by nature. Ask whether there is a health view showing when each one last ran successfully. If the vendor has one, they have been burned and have learned something. If they look puzzled by the question, your event reminders will stop going out one Tuesday and nobody will find out until a member mentions it.
The trap in the answer: "we monitor it" usually means an alert fires when a job errors. The failure mode that costs you members is a job that stops being scheduled — it never errors, it just never runs, and an error-based monitor is silent for exactly that case.
8. "What is the smallest thing I cannot change?"
Invert the demo. Instead of asking what it does, ask where it is rigid.
Every platform has opinions baked in. Ours: no custom CSS, curated themes only; segments are static lists rather than saved queries; there is no drag-and-drop reordering anywhere, only move-up and move-down; a learning pathway's lock order is not configurable.
Some of those will be dealbreakers for you. Good — that is a five-minute discovery instead of a five-month one. A vendor who cannot name a single rigid thing about their product either does not know it well or is not being straight with you, and neither is what you want.
9. "How many people work on this, and how do I reach them?"
Not a snobbish question. A large platform gives you stability, an ecosystem and a support queue. A small one gives you a person who answers and a roadmap you can actually influence. Both are legitimate. What you cannot have is a small team's responsiveness with a large company's guarantees, and any answer implying otherwise is marketing.
The meta-advice
Do not run a trial by clicking around the admin panel. Run it by putting five real members into it for two weeks and watching what they do.
You will learn more from one confused message — "where do I find the thing from last Tuesday?" — than from any feature grid. Every platform in this category demos well. They differ in what they are like to live in.
If you want to try ours, Klaas Academy is free while it is in early access, no card. And if one of the rigid things in question 8 is a dealbreaker for you, I would rather you knew now.