Choosing forum software for a small community
Most advice about community software is written for communities that already have members. The problems of a board with thirty people are almost the opposite ones, and the software choice that solves them is different.
A large forum's difficulties are volume: moderation load, search quality, storage, keeping the front page from becoming noise. A small forum has none of those and one enormous problem instead. It looks empty, and looking empty is self-reinforcing, because the person who might have posted decides the room is dead and leaves.
Everything below follows from that. The right platform for a small community is the one whose empty state is least discouraging and whose maintenance cost is closest to zero, because the scarce resources are attention and momentum rather than capacity.
The empty-room problem is a design problem
Platforms differ enormously in how they present a quiet board, and it is rarely mentioned because it is invisible once a community is busy.
A traditional board — categories with counts, threads listed below — degrades gracefully. Four topics in a category reads as a small board, which is accurate and unembarrassing. The structure carries the page even when the content is thin.
A platform built around activity does the opposite. Reading positions, unread indicators, real-time updates and "latest" feeds all imply motion, and when there is none they make the absence conspicuous. Discourse and NodeBB are both excellent software that can make a twenty-post board feel like an abandoned building, purely because their interfaces are designed to convey flow.
This argues, unfashionably, for the older-looking option at small scale. A board that looks like a board sets an expectation it can meet.
Do not provision for the community you hope for
The instinct is to choose the platform that will still work at fifty thousand members. It is the wrong instinct, because the overwhelming majority of small communities never get there, and the cost of the capable option is paid every month from the beginning.
Concretely: a PHP board on shared hosting costs a few pounds a month, upgrades in an afternoon, and can be handed to somebody else when you lose interest. A containerised application with a separate database and cache costs more, requires somebody who understands it, and becomes unmaintainable the moment that person stops being available. For thirty people the second option buys nothing at all.
If the community does grow past what the simple option handles, that is a good problem arriving with an obvious solution and, by then, people who care about solving it. Migrating a busy board is work. Migrating a board that never got busy is work you did for nothing.
Which platforms actually suit a small room
The traditional PHP boards — phpBB, MyBB, Simple Machines — are the honest default. They install on almost any hosting, they need no runtime beyond PHP and MySQL, their interfaces are legible to people who have used a forum before, and a quiet one does not look broken.
Flarum deserves consideration for the same reasons with a more modern surface: it is a small PHP core, it installs where PHP installs, and its extension mechanism fails loudly rather than quietly. It looks contemporary without requiring the operational apparatus that usually accompanies that.
Where the community is attached to an existing site, an embedded option changes the calculation entirely. Vanilla and Talkyard both sit inside a page you already own, which means the community does not have to be a destination in its own right — and for a small group, not having to be a destination is a large advantage.
Mobile is most of the room
Whatever the traffic split is on a large board, a small community's members read it on a phone between other things. A platform whose default theme is awkward at narrow widths loses replies that would otherwise have been written, and the loss is invisible because nobody reports a post they did not make.
This is worth checking on an actual phone before committing, not in a resized browser window. What to look for is unremarkable: whether the reply box is reachable without scrolling past the whole thread, whether quoting works with a touch keyboard open, and whether the category list is one tap away rather than three.
Seed it before you invite anyone
A board opened with zero content gets zero replies. Before the invitations go out there should be something to reply to: a handful of real topics, in the categories you intend people to use, written the way you want the room to sound.
Fewer categories than feels right. Three is usually correct at the start. Eight categories across thirty people produces eight empty rooms, and each one is a small signal that nothing is happening. Categories can be added when a conversation is repeatedly happening in the wrong place, which is the only reliable evidence that one is needed.
Moderation when you know everyone
Human moderation is easy at this size and technical moderation is still necessary, because the spam does not care how small you are. An open registration form is found by automated signups within days of going live.
The settings that matter are approval for first posts, a registration question that a script cannot answer, and a rate limit. All three exist on every platform discussed here, and all three are commonly switched off during the quiet early months because they add friction — which is exactly when the board is least able to absorb the consequence.
Search matters more here, not less
It is tempting to treat search as a problem for large boards. The opposite is closer to true. A small community's entire value is the handful of good answers buried in it, and those answers are outnumbered by chat, greetings and threads that went nowhere. If they cannot be retrieved, the board has an archive that functions as a landfill.
At this size the database-backed search in the traditional boards is genuinely adequate, which is one more reason not to over-provision. What is not adequate is leaving the board unindexable. A small community that closes itself to search engines has removed the only route by which a stranger with the same question would ever have found the answer — and strangers with the same question are how small communities grow.
Plan for the maintainer leaving
Small communities are usually kept alive by one person, and the failure that actually kills them is not a technical one. It is that person losing interest, changing jobs, or simply getting busy, with nobody else holding a password.
Two cheap precautions. Give a second person full administrative access from the start, before it is needed rather than after. And write down, somewhere that is not one laptop, where the hosting is, where the domain is registered, and how a backup is restored. A community that survives its founder's departure is almost always one where those three facts were written down while nobody thought it mattered.
This is also a reason to prefer the boring platform. Handing over a PHP board on shared hosting is a plausible ask of a volunteer. Handing over a container deployment is not, and a board nobody can take over has a scheduled end date whether or not anyone has noticed.
When a forum is the wrong tool
A forum earns its keep when answers are worth finding later. If the group's conversation is mostly coordination — arranging things, reacting to things — a chat server fits better, and nobody has to pretend a thread structure is useful.
A mailing list remains an excellent and unfashionable answer for a group that is already reading email. It has no empty-room problem at all, because it has no room.
And if the requirement is really comments under articles, a comment server is a fraction of the work and does not create a second place that has to look alive.
What it costs to run, in hours
The monthly bill is the easy number and the least useful one. The figure worth estimating before committing is hours, because that is the resource that runs out.
A quiet board on stable hosting needs roughly an hour a month once it is running: clearing the spam queue, approving first posts, applying a point release. That is genuinely small, and it is why the boring option keeps winning — an hour a month survives a busy quarter at work.
What breaks the estimate is a major version upgrade, which arrives every year or two and takes an afternoon on a clean installation and a weekend on a modified one. If the board has accumulated a dozen patched-in modifications, that weekend recurs and grows, and it is the single most common reason a small board ends up frozen on an unsupported release.
The practical discipline is to keep the installation close to stock. Every modification is borrowed against a future upgrade, and on a board with thirty members the feature is rarely worth the debt.
Deciding, briefly
Pick the platform your hosting already supports. Create three categories and eight topics. Turn on first-post approval and a registration question. Invite people in small batches rather than all at once, so early threads have replies before the next group arrives.
Revisit the software choice when something specific about it is blocking you, and not before. The board that succeeds is almost never the one that picked better software; it is the one where somebody kept posting.
Questions people actually ask
Does a small community need different software?
It needs different weighting, not different software. At thirty people the moderation tooling that matters at thirty thousand is idle, and the operational burden — a second language to patch, a second database to back up — is carried by the same one or two people who also write the posts. That shifts the answer towards the boring platform almost every time.
How small is too small for a forum?
There is no floor in the software; there is one in the traffic. A board with four posts a week still reads as a board on a traditional layout, and reads as abandoned on a design built for volume. That is a reason to prefer the older shapes at small scale rather than a reason not to start.
Is a hosted service better for a small group?
Often, and the honest comparison is against hours rather than against features. What self-hosting buys is control of the data and the addresses; what it costs is the patching, the upgrades and the night the site is down. A group with nobody to spend that on is not saving money by running it themselves.
What is the most common mistake at this size?
Choosing for the community you hope to have. The platform that suits a thousand members is usually harder to run and emptier-looking at thirty, and the migration away from it costs more than starting on the simpler thing would have. Pick for the room you have; the catalogue records which platforms have an exit.