How to Build an App Like Discord: Architecture, Compliance, and Cost

They fail since the team had planned a messaging app and released it on a community platform; the two are different systems.

Messaging is simple; it only takes two people, a single conversation, and one way of delivering the message. A capable team can have it ready within weeks.

Community platforms fail when it comes to handling fanout. A single message in a crowded room has to be sent out at the same time to thousands of clients who are using the system, in the correct order and with accurate unread count information. It is this aspect that causes the builds to stall.

Discord reached this very limitation; their engineering team noted that when the number of members was 100,000, it meant that a new list of 100,001 had to be created each time someone joined. Their pure Elixir approach only managed to get up to a ceiling of about 250,000 members before they rewrote the data structure in Rust (Discord engineering).

A company which has a dedicated infrastructure organization reached a scaling limit with respect to one data structure, and your first version will encounter smaller versions of that limit much earlier.

Most of the guides produced by agencies omit this point. Instead of explaining where a system fails, they give a list of features and a price range.

A real-time community platform is group software that is arranged according to rooms, roles, and presence, rather than around individual conversations.

Discord refers to its rooms as guilds, and Slack refers to them as workspaces.

The way you build your system has an impact on both your architectural design and your level of regulatory exposure. You should decide in advance which type of system you are going to build before you start planning the work.

If the rooms that your product provides are open for strangers to join, then you are creating a community platform; under EU law you are considered an online platform rather than a private chat service since your rooms are open to a broad audience rather than a fixed group of people.

If you get it wrong, you'll carry out the wrong compliance work. That is one of the more costly mistakes available at this stage.

Starting from scratch is generally the incorrect approach; most of the teams who ask this question are looking to create a community product, not a real-time infrastructure company.

Honestly, sometimes you should build. If real-time behavior is your actual edge, or data residency rules block hosted vendors, owning the stack is right. Most founders do not have that constraint.

The fork option carries a trap that almost no guide flags. Open source here rarely means unrestricted.

Previously known as Revolt, Stoat is distributed under the AGPL v3, a license that imposes copyleft obligations when you deploy modifications over a network. Mattermost employs a Source Available License that permits free use for development and testing but requires a paid Enterprise license for use in production (as stated in the Mattermost documentation). Rocket.Chat is based on the MIT license, with some components covered by a separate paid license.

Read the licence before you plan the fork, not wait until your lawyer has dealt with it. Three projects all claiming to be open source impose three different duties upon you.

Licensed infrastructure has a definite form; in this case, vendors charge according to the number of monthly active users and also impose a limit on the number of simultaneous live connections based on a second meter, with additional charges applied to that meter. Since community apps experience sharp spikes during events, it is the connection meter that causes problems for the teams.

The four issues are connection management, presence, fanout, and the unread state; all the rest constitute work concerned with the product.

The management of connections is the fundamental issue. Each user who is online has an open socket, and your servers have to keep track of it, authenticate it, and then clean it up. The number of concurrent connections, not the number of registrations, decides the size of your infrastructure.

It appears to be more difficult than it at first sight. When someone's presence is shown, each change of status is transmitted to all those who can see that user. The number of messages that are generated increases as the number of rooms the person has joined increases.

It is within the area of budgeting that deaths occur. Discord has devised a separate procedure for each community so as to keep track of who is connected and to send each new message on to those sessions. They took years to refine that design.

The unread state is a quiet one. The figures shown for badges and mention counts have to stay accurate whether the user is online or offline and even when messages are deleted. Teams fail to do this and release a product in which the badge is incorrect.

The order used in the messages completes the set; in order for posts that are made at the same time to be seen in the same order by every reader, the server has to assign a sequence rather than relying on the clients' clocks.

It is important to choose a topology from the beginning since altering it later would be like doing a rewrite. The two options are a peer-to-peer mesh or a Selective Forwarding Unit, referred to as an SFU.

To function, Mesh requires each participant to send their stream directly to all other participants, and the maths shows this quickly becomes unviable. For a call involving ten people, each client has to upload nine separate streams, and the home upload bandwidth is exhausted long before any other resource is.

The SFU takes the stream from each client and forwards it on to the others. The client upload requirements therefore remain the same no matter how many participants there are. Since the clients still have to decode one stream per speaker, the SFU increases the ceiling rather than eliminating it.

From the start, when designing a product similar to Discord, plan to use an SFU. The core feature is for people to join and stay in voice rooms all evening, and Mesh can't support that.

List budget media servers as a separate item. Voice isn't something you add to a chat backend; it is a separate system with its own scaling requirements and operational workload.

When choosing concurrency features, don't pick them based on what your team knows best; the gateway layer has requirements the rest of your product doesn't.

Discord's choice is worth adopting: it uses Elixir for real-time traffic because its processes are cheap, and switches to Rust where the BEAM proves too slow.

Use a high-concurrency runtime for the gateway, and only when necessary at points proven to be slow, opt for a systems language; choosing Rust from the start will result in slower delivery rather than faster.

If JavaScript is the strongest point of your team then a Node.js development gateway is an appropriate first choice. Just be aware that, unlike a BEAM stack, you'll have to manage connection state yourself.

Any published figure is just an estimate, since vendor blogs quote ranges that vary by a factor of ten for the same request because they don't know your scope.

That is why we do not provide a range here. All we can do is give you the list of options that change the number so you can have a quote conversation with the variables already fixed.

Recurring items teams tend to overlook include media bandwidth, message storage growth, moderation staffing, and ongoing compliance review, since these continue after launch.

The quote given for the build does not represent the cost of the product; you should model the system for twelve months before finalizing a topology.

It takes longer than a typical app because two phases involve infrastructure work users never see; those phases are planning brackets for scope discussions, not a quote.

Don't rush the first phase; teams that skip regulatory scoping have to redo their moderation and identity layers later, and that's the most costly rework in this category.

Three regimes currently apply to user-to-user services, and all are in force today. This section distinguishes a genuine build plan from a simple feature list.

The UK duties are the sharpest. Ofcom asks in-scope services to weigh the risk of priority illegal content against their risk profiles, implement the applicable safety measures, and keep records of that work (Ofcom illegal content duties). Ofcom's Protection of Children Codes took effect on 25 July 2025. Financial penalties reach 18 million pounds or 10% of global turnover, whichever is greater.

Age assurance and moderation tooling are not secondary features; they are a condition of trading in the UK.

In 2026, the US position became firmer. The FTC's amended COPPA rule came into force on 23 June 2025, with a compliance date of 22 April 2026, which has now expired (Federal Register). What was once a grace period is now a real risk.

The EU has classified its rules in different tiers, with small and micro enterprises being exempt from certain heavier duties. In contrast, the Very Large Online Platforms tier begins at above 45 million monthly EU users (European Commission). You remain subject to the base notice and action duties from the very first day.

Discord's difficulties with its 2026 age verification system are a case in point: although the platform had mature systems in place and a large safety team, the public launch still went wrong. This task is harder than it seems at first.

Most failures after a system goes live are operational rather than technical; systems that pass load tests still break down in real use for obvious reasons.

Migration issues beat architecture problems, since network effects act as a barrier to entry; a better platform with no users loses to a worse one that already has people using it.

Two related reads shape how you plan the rest of the build. Our guide on PWA development pricing covers how delivery choice moves cost, and our piece on building scalable and secure platforms covers the load work that applies here too.

This is the only part in which we move away from behind the curtain.

Cypherox builds real-time B2C communication and collaboration platforms and B2B collaboration systems for teams that need community software they own. We settle the topology and legal scope before any product code, because those two choices drive everything that follows.

Our teams work across cross-platform app development and backend engineering, building social networking and community products where concurrency is the primary constraint.

If licensed infrastructure is the right answer for you, we say so during scoping rather than after a contract.