Websites

Social network or community: where a platform begins

What really needs deciding before building a social platform: feed rules, profile privacy, moderation from day one, and one scenario instead of copying the big networks.

A request to "build a social network" usually arrives with a feature list copied from existing platforms: feed, profiles, follows, likes, comments, messages, stories, groups. Technically, all of that can be built. The problem is that a working community doesn't come from a set of features but from the rules by which people interact in it. Here's what needs deciding before development begins.

One scenario instead of everything at once

The big social networks look universal, but each started with a narrow scenario and was built out over years for an audience it had already gathered. You can't reproduce the end state at launch: a new platform has neither the audience those features were designed for nor the data to know which of them are needed.

The practical approach is to pick one action people will come back for, and do it well. For example:

  • specialists post their work and get feedback from peers;
  • members of a private club ask questions and answer each other;
  • neighbourhood residents post listings and discuss local news.

Everything else is built on top of that action. If it doesn't work, no additional features will save it: on an empty platform, there's nothing for a user to do but leave.

This also sets the order of development. First — posting and responding. Then — ways to discover interesting things. Then — everything else. The reverse order produces a platform with excellent privacy settings and an empty feed.

The feed and its rules

The feed is the main screen and the main source of arguments. Before designing it, answer the question: by what principle does the user see exactly this?

The main options:

  1. A chronological feed of follows. Simple, predictable, fair. It works while the user follows a reasonable number of sources. With many follows it drowns in noise; with few it looks empty.
  2. A feed of communities or topics. People choose topics, not people. Easier at launch: a newcomer doesn't need to find anyone for the feed to fill up.
  3. Ranking by activity. Whatever got a response rises to the top. It livens up a platform with little content, but needs protection against manipulation and creates an effect where the same authors take over the whole feed.

For a new platform it's usually sensible to start with the second or third option: an empty chronological feed is a typical reason a new sign-up doesn't come back.

The cold-start question is decided separately. What does a person see in the first minute after signing up? If the answer is "nothing, until they follow someone", the platform loses most new users at that step. You need a pre-filled option: a set of topics, recommended authors, at least an editorial feed.

Profiles and privacy

A profile isn't a page with an avatar but a set of decisions about what's visible about a person, and to whom.

The minimum list of questions to answer before development:

  • Is a profile visible to everyone, only to registered users, or only to approved contacts?
  • Are profiles indexed by search engines? This affects both audience inflow and people's willingness to post under their own name.
  • Is the list of follows and followers visible? For a professional community, usually yes; for a platform about personal matters, often no.
  • What happens when an account is deleted: are comments removed, do they stay as anonymous, what do people who replied to them see?
  • Can a user be blocked, and what exactly does blocking hide?

The last point seems minor, but blocking is a basic safety tool. Without it, a person facing harassment can only leave the platform.

Privacy settings don't define the interface; they define which people will still be in the community a year from now.

Data is a separate topic. A social platform by its nature collects a lot of personal information, and requirements for storing, deleting and exporting it have to be built into the architecture, not added later. Related questions are covered in the security section.

Moderation from day one

A common misconception: moderation will be needed once there are lots of users. In reality it's needed from day one, because the first few dozen members set the tone that then gets reproduced.

What should be ready at launch:

  1. Community rules in plain language: what's allowed, what isn't, what happens for a violation. Without them, any moderator decision looks arbitrary.
  2. A report button on every object — post, comment, profile, message. With a choice of reason: spam, abuse, someone else's content, other.
  3. A report queue in the admin panel with a clear set of actions: hide, delete, warn, restrict posting for a period, block.
  4. Automatic limits for new accounts: a posting limit in the first days, a delay before direct messages are allowed, restrictions on external links. It's not paranoia but basic protection against the spam that comes to every open platform.
  5. A moderator action log, so decisions can be reviewed and explained.

Importantly, moderation is people's work, not just a tool. A report queue can be built, but if nobody works through it, the effect is zero. Who exactly will do this and how much time they'll spend is a question settled before launch.

Load and notifications

A social platform differs from an ordinary website in the nature of its load. Where a corporate site user reads a ready-made page, here every feed request is a query that depends on a specific person's follows. It can't be cached as a whole.

Key technical points:

  • Building the feed. At small volumes, assembling it on the fly with a query is enough. As it grows, that stops being enough, and the feed starts being built in advance at publication time. It's better to allow for the switch between these approaches in the architecture from the start, so the whole system doesn't have to be rewritten later.
  • Media. User photos and videos are the bulk of storage and traffic. You need processing on upload, several sizes, delivery through a CDN and file size limits.
  • Notifications. The most underestimated part. Every action generates notifications, and in an active discussion a person receives dozens. You need grouping ("five people replied to your post" instead of five emails), settings by event type, and digests instead of instant emails where urgency isn't needed.

Badly tuned notifications are a common reason people switch them off entirely and then stop visiting, because nothing brings them back.

Where to start in practice

The sequence of steps before developing a social platform:

  1. State in one sentence the one action people will come back for.
  2. Describe what a new user sees in the first minute, before they've followed anyone.
  3. Choose the feed principle and explain why it suits your audience.
  4. Draw up a privacy table: what's visible to everyone, to registered users, to contacts, to no one.
  5. Write the community rules and decide who handles reports and how quickly.
  6. Define which events generate notifications and how they're grouped.
  7. Estimate how much media you're prepared to store and serve.

If all seven points have answers, the specification is essentially ready. More on how we build such platforms is in the social networks and communities section.