Users used to accept refreshing a page to get updated information. That tolerance has largely gone. When someone opens a project management tool and a colleague updates a task, they expect to see it without reloading. When an order is processed, they expect a notification to appear. When a dashboard shows operational data, they expect it to reflect what is happening now, not what was happening when they opened the tab.
Real-time web application features, the technical layer that makes pages update themselves as data changes, have moved from differentiator to expectation. The question for most product owners planning a new application is not whether to include them, but which ones, at what cost, and where the complexity actually lives. Those answers are less obvious than the feature names suggest.
What real-time actually means in a web application
Standard web applications operate on a request-response model: the user or browser asks the server for data, the server responds. This works well for content that changes infrequently. It fails when data changes constantly and users need to see those changes as they happen, without asking.
Real-time features replace or supplement this model with a persistent connection between the browser and the server. Instead of the browser asking repeatedly, the server can push data the moment something changes. The result is a page that updates itself, without reloading, as events occur.
The range of what falls under real-time is wide, and the technical complexity varies significantly across that range. A live counter that increments when a new order arrives is technically real-time but relatively straightforward to build. A collaborative document editor where multiple users type simultaneously and see each other's changes is also real-time, but carries an order of magnitude more engineering complexity. Understanding which type of real-time your application actually needs is the most important early decision.
The five most common real-time features and when they make sense
Live notifications: An alert appears when something relevant happens, without the user having to check. New message, task assigned, order confirmed, payment received. These are the most frequently needed real-time feature and, relative to their value, among the simpler ones to implement correctly. Relevant for almost any business application where timely awareness of new events changes what a user does next.
Activity feeds: A running stream of events, either personalised or shared across a team, that updates as activity occurs. Useful in operations dashboards, project tools, internal platforms, and anywhere multiple users need visibility into what is happening in real time. The feed structure itself is relatively straightforward; the complexity lies in filtering what each user should see and keeping the feed performant as event volume grows.
Chat and messaging: Two-way text exchange that appears for all participants as it is sent. More complex than notifications because messages must reach multiple recipients reliably and in order. User expectations for chat are high: sent and delivered indicators, typing indicators, message history, and read receipts are all baseline expectations drawn from consumer messaging apps. Building these correctly takes meaningfully more time than product owners typically anticipate. Custom web application development that includes messaging features requires careful scoping of exactly which sub-features are necessary before a build commitment is made.
Live dashboards: Data visualisations that update as the underlying data changes. Sales pipeline counts, operational status boards, stock levels, logistics tracking. Particularly valuable where decision-makers need current figures rather than a stale snapshot. The engineering complexity scales with how frequently data changes and how many metrics are being tracked simultaneously.
Collaborative editing: Multiple users modifying the same record or document simultaneously, with each seeing others' changes as they happen. The most technically demanding of the common real-time features. Conflict resolution, what happens when two users change the same field at the same moment, requires careful engineering. Worth building for specific use cases but unnecessary for most business applications that handle these situations by locking records while one user edits.
WebSockets, server-sent events, and polling: what the difference means for your build
Three primary mechanisms deliver real-time data to a browser. Product owners do not need to choose between them, but understanding the tradeoffs helps ask better questions when scoping a build.
Polling: The browser sends a request every few seconds asking whether anything has changed. Simple to build and works everywhere, but inefficient. For features where data changes infrequently, every 30 seconds or more, polling is often the most pragmatic approach. For high-frequency updates or large numbers of concurrent users, the constant stream of requests becomes expensive and adds latency.
Server-Sent Events (SSE): The server holds open a connection and pushes data to the browser when something changes, but the communication is one-way: the browser receives, it cannot send via the same connection. Simpler than WebSockets and sufficient for most notification and dashboard use cases where the feature is about receiving updates. This approach is underused relative to how well it fits common requirements.
WebSockets: A persistent, two-way connection. Data can flow in both directions at any time without either party needing to initiate a request. The right choice for chat, collaborative editing, and any feature requiring immediate bidirectional communication. More complex to build and operate correctly, and requires infrastructure designed to handle many simultaneous persistent connections. Often specified when SSE would have been sufficient, adding cost and complexity without meaningful user benefit.
The choice between these should be driven by whether the feature requires two-way communication and how frequently data changes. A development partner who asks these questions before recommending an approach is more likely to suggest the right one for the use case rather than the most technically interesting one.
The infrastructure reality that product owners underestimate
Real-time features do not just add frontend complexity. They change the server-side architecture of an application in ways that carry direct cost and reliability implications.
A standard web application scales horizontally: add more servers, route requests between them, handle more traffic. WebSocket connections are persistent and stateful: a user connects to a specific server and stays there. Adding a second server does not automatically allow it to communicate with connections held by the first. This requires a message broker, Redis being the most common, that coordinates state across servers. At small scale this adds modest complexity and cost. At large scale it becomes a primary engineering concern that needs to be designed for upfront.
According to research from Ably, an infrastructure platform for real-time systems, engineering teams consistently underestimate the effort required to make real-time features reliable at scale by a factor of two to three compared to initial estimates. The feature code itself is rarely the hard part. Handling reconnection after a dropped connection, queuing events that occur while a user is offline, and ensuring delivery under real network conditions is where the engineering effort accumulates.
In the South African context, where network quality varies significantly outside major urban centres and power interruptions can cause connectivity drops, real-time features need robust offline and reconnection handling to work reliably for the actual user base. An application that silently shows stale data when connectivity drops, with no indication to the user that the data is no longer live, creates confusion and erodes trust. Designing for graceful degradation is not optional for most South African business applications.
Where real-time builds typically go wrong
Underspecified scope: A live notifications feature sounds bounded. In practice it tends to expand during development to include notification preferences, read and unread state, notification history, mobile push alongside in-app, and email fallback for offline users. Each is a real engineering addition. Agreeing on the minimum viable version before development starts produces significantly better outcomes than discovering requirements mid-build.
Insufficient scale testing: A WebSocket feature that works smoothly for 10 concurrent users may fail completely under 1,000 simultaneous connections. Load testing real-time features requires simulating concurrent persistent connections, not just request volume. This is a different kind of testing from standard performance testing, requires appropriate tooling and planning, and is consistently underprioritised in project timelines.
Treating real-time as a frontend addition: Product owners sometimes request real-time features late in a build, framing them as a layer to be added to an existing system. Real-time data delivery often requires changes to how data is stored and how events are emitted at the backend. Late additions to architecture are always more expensive than designing for them from the start. If real-time is a known future requirement, flagging it before the initial build begins allows the data model to be designed with it in mind.
How to decide which real-time features your application actually needs
The right filter is not whether a feature would be impressive, or whether users might appreciate it. It is whether the feature changes what users can do with the application, or how reliably they can do it.
A notification that appears when a colleague assigns a task changes behaviour: the assignee acts immediately rather than discovering the task on their next login. A counter that shows the total number of records in a database in real time probably does not change what any user does with that information. The first delivers business value. The second is technically interesting without changing outcomes.
Before committing to a real-time feature, ask: what does the user do differently because of this information arriving now rather than on their next page load? If the honest answer is not much, a simpler approach delivers most of the value at a fraction of the cost. A page-refresh prompt, a periodic background sync, or a manual refresh button are legitimate solutions for data that does not require true real-time delivery.
This is the kind of scoping conversation worth having before a build brief is written. Platform and product decisions made at the brief stage are reversible. Decisions made after six weeks of development are not. The most effective product owners treat real-time as a targeted capability applied to specific high-value interactions, not a default upgrade applied to all data in the system.
Frequently asked questions
Do I need WebSockets for notifications?
Not necessarily. Notifications that do not require immediate two-way communication can be delivered effectively via Server-Sent Events, which are simpler to build and operate. WebSockets are the right choice when users need to send data back to the server in real time, as in chat, or when SSE latency is insufficient for the specific use case. Most notification systems do not need WebSockets.
How much does a real-time feature add to a build?
It depends on the feature type and the existing architecture. A simple notification system added to an existing application typically adds two to four weeks of development. WebSocket-based chat with presence indicators, message history, and offline handling can add six to ten weeks. Infrastructure additions and scale testing are often as significant as the feature code itself, and are frequently underestimated in initial timelines.
Will real-time features increase my hosting costs?
Yes, meaningfully for large user numbers. Persistent connections consume server resources even when no data is being exchanged. At small scale, under a few hundred concurrent users, the increase is modest. At large scale, real-time infrastructure can become a significant hosting cost line. Your development partner should model expected costs against your anticipated user numbers before the feature is built, not after.
Can real-time features be added to an existing application?
Usually yes, but retrofitting costs more than building in from the start. If real-time is a known requirement for a future phase, it is worth designing the data layer with it in mind during the initial build, even if the feature itself comes later. This avoids significant refactoring costs when the time comes and is one of the more valuable things to flag early in a build conversation.
Which applications benefit most from real-time features?
Applications where users make time-sensitive decisions based on changing data: operations dashboards, logistics tracking, project coordination tools, sales pipelines, and anything involving multi-user collaboration. Applications primarily serving individual users consuming relatively static content benefit less, and often find that simpler update mechanisms deliver equivalent value at meaningfully lower cost.
Book a free consultation with CodeLab One to discuss which real-time features your application genuinely needs and the right technical approach for your user base and scale.
