~11 min read · "And it should be real-time, of course." It's one of the most casually-asked-for features in mobile development, and one of the most expensive to actually deliver. The cost gap between what most buyers ask for and what they actually need is staggering. Here's the framework.
There's a moment in almost every app-scoping conversation when the buyer drops a particular phrase. It usually arrives near the end of describing a feature, as a kind of casual flourish.
"Oh, and the notifications should be real-time, of course."
"The feed should update in real-time."
"When someone leaves a review, the seller should see it in real-time."
The buyer doesn't pause on this phrase. They don't think they're asking for anything dramatic. It's the same phrase they use when they talk about Uber updating in real-time, or Slack showing new messages in real-time, or their bank app showing balance changes in real-time. It's just the modern texture of what an app is supposed to feel like.
The developer hears something different. They hear a request that might cost five times what the rest of the feature does. They hear an architectural decision that will affect every other feature in the app for the next three years. They hear something they should ask follow-up questions about — and depending on the answers, the cost of the project could go up dramatically, or stay roughly where it was.
This article is about that gap. What "real-time" actually means. The three very different things it can mean. What each of them costs. And — most usefully — how to figure out which one your specific feature actually needs.
The Phrase That Means Three Different Things
The English word "real-time" maps onto at least three meaningfully different technical realities. They look the same from the user's seat. They cost wildly different amounts to build.
Tier 1: Refresh-based. The app fetches new data every so often — every 30 seconds, every minute, every time the user opens a screen. The feature appears real-time because the user doesn't usually notice the gap between when something changes on the server and when the app reflects it. From the user's perspective: it's live. From the infrastructure perspective: it's almost free.
Tier 2: Eventually-consistent. The app uses some combination of push notifications, server-sent events, or background sync to update most changes within seconds, rather than minutes. This is what most modern apps use for most of their "real-time" features. It looks live. Most of the time it is live, to within a few seconds. It costs noticeably more than tier 1, but it's not prohibitive.
Tier 3: True real-time. A persistent connection between the app and the server (a WebSocket, or a similar technology). The moment something changes anywhere, every connected client sees it within milliseconds. The user experience is instant — no perceptible lag. This is what powers chat apps, multiplayer games, live trading platforms, collaborative document editors. It's expensive to build, expensive to operate, and expensive to debug.
Almost every casual "should be real-time" request actually wants tier 1 or tier 2. The buyer's mental model is "the user should see the new thing without having to manually refresh". That's tier 1. The number of features that genuinely require tier 3 is small — and for those features, the cost is justified. The problem is when tier 3 is built when tier 1 would have been fine.
What Each Tier Actually Costs
Let's put numbers on this, with the caveat that local market rates and app complexity vary widely.
Tier 1 (refresh-based) is essentially free. The app already has to fetch data when the user opens a screen. Refreshing periodically — say, every 30 seconds when the screen is visible — is a few lines of code. The infrastructure cost is whatever the existing data-fetching costs already are. Maybe a few percent higher. There's no architectural impact on the rest of the app.
Tier 2 (eventually-consistent) adds real but bounded cost. You're typically adding a push notification service (or similar background mechanism), some backend code that emits events when relevant data changes, and some mobile code that listens for those events and updates the UI. Total engineering: maybe $3,000–$8,000 of additional work for a feature, depending on complexity. Infrastructure cost: tens of dollars per month at low scale, scaling roughly linearly with active users.
Tier 3 (true real-time) adds substantial cost. You need a server architecture that can maintain persistent connections — which is fundamentally different from the request-response architecture most backends are built around. You need client code that manages connection state, reconnects after network drops, handles message ordering, deals with conflict resolution. You need backend infrastructure that scales differently — connection pooling, load balancing for long-lived connections, message routing. Total engineering: $20,000–$50,000 of additional work for a serious implementation, sometimes much more. Infrastructure cost: hundreds to thousands of dollars per month at moderate scale, with steeper scaling.
The cost ratio is roughly 1x : 3x : 10x. Tier 1 is essentially free. Tier 2 is a small extra spend. Tier 3 is a major architectural commitment.
The instinct to "just build it real-time from the start" — under the theory that it's easier to do up front than to retrofit later — is usually wrong. It's harder, more expensive, and shapes every other decision about the app. Building tier 1 and upgrading specific features to tier 2 or tier 3 when they need it is almost always the better path.
What Products Actually Need Each Tier
The most useful exercise is to look at categories of features and name which tier each genuinely needs.
Notifications about something happening to the user personally — someone replied to your comment, your order shipped, your payment went through. These almost always need tier 2. The user needs to know within seconds, not minutes. But they don't need instant. Tier 2 (push notifications + a refresh on app open) is the right answer.
A social feed of new posts. Tier 1 or tier 2. The user opens the app; they see new posts. If they're staring at the feed for ten minutes, a periodic refresh every 30 seconds is more than enough. Tier 3 would be massive overkill.
A counter — likes, view counts, follower counts. Almost always tier 1. The user doesn't need to see the like count tick up in real-time. They need to see the current count when they look. Refreshing on screen open is fine.
Live chat between users. Tier 3. This is one of the canonical cases. A chat that lags by 30 seconds feels broken. Users expect typing indicators, immediate delivery, read receipts. WebSockets are the right tool.
Collaborative editing (a document, a whiteboard, a shared list). Tier 3, with conflict resolution. This is genuinely hard. There's a reason Google Docs is one of the most-engineered consumer products in history.
Multiplayer games. Tier 3, full stop. And often with custom protocols on top — UDP rather than TCP for latency-sensitive games.
Live trading or auction interfaces. Tier 3. Milliseconds matter. The whole product is the real-time.
A "live location" feature in a delivery app. Tier 2 or tier 3, depending on how live. Updating the driver's pin every 5–10 seconds is tier 2 and is what most delivery apps actually do. Updating it every 100 milliseconds is tier 3 and is mostly unnecessary.
Sports scores, news headlines, "what's trending." Tier 1 with a quick refresh. Maybe tier 2 for true breaking moments. Tier 3 would be expensive and unnecessary.
A useful test: ask whether your feature is closer to chat (where lag is felt as a defect) or to a feed (where lag is barely perceptible and a 30-second refresh is fine). The chat-like features need tier 3. The feed-like features almost never do.
The Architectural Decisions That Determine Your Tier
Once you know which tier you need, several specific technical decisions follow. You don't need to make these decisions; your developer does. But you should know they exist, because they're often where the cost gap shows up in an estimate.
Polling vs. push for tier 2. If you're going eventually-consistent, you can either have the app poll the server frequently, or have the server push updates to the app. Polling is cheaper to build but more expensive to run at scale (more requests, more battery use). Push is more expensive to build but cheaper to run. A serious tier 2 implementation usually uses push.
WebSockets vs. server-sent events vs. long polling for tier 3. Different technologies for maintaining a persistent connection. WebSockets are the dominant choice for most modern apps. Server-sent events are simpler but one-directional. Long polling is older and rarely used now. The choice affects the engineering cost; the user experience is roughly the same.
Connection management on mobile. Mobile devices drop connections constantly — when the user switches networks, when the phone goes to sleep, when the user moves between cells. A serious tier 3 implementation has to handle this gracefully. The code that manages connection state and message redelivery is often the most expensive part of the implementation.
Backend scaling shape. A traditional backend handles many short-lived requests. A real-time backend handles few long-lived connections. The scaling math is fundamentally different. Some backends (Node.js, Go, Elixir) are well-suited to this; others (traditional Rails, Django) need significant adaptation. The backend choice you made earlier in the project may or may not support a real-time addition cleanly.
This last point is the most consequential, and it's the reason "let's add real-time later" sometimes turns into a much bigger project than expected. The backend may need to be restructured to support real-time, which is part of why we recommend, in your app's backend might not actually be a backend, that the choice of backend is one of the most consequential decisions in the early phase of a build.
The Battery Cost Nobody Mentions
There's a real-world cost to real-time that almost never shows up in estimates: the user's battery.
A tier 1 feature uses almost no battery — the app fetches data when it's already running, and otherwise sleeps. A tier 2 feature uses a small amount more — push notifications wake the app briefly, then it sleeps. A tier 3 feature, with a persistent connection, keeps a network connection alive constantly. This costs more battery, and on mobile devices, it costs visibly more battery in some cases.
This matters because users notice battery-draining apps. They appear in the iOS and Android battery usage screens. Users uninstall apps that show up there.
A serious tier 3 implementation has to manage this carefully — using OS-provided mechanisms for low-power connections, suspending and resuming intelligently, using push notifications instead of persistent connections when the app is in the background. This adds engineering complexity beyond "just open a WebSocket."
The battery cost is the part of the real-time conversation that's almost never discussed in scoping. It's also the part that, when handled badly, can sink a launch. An app that drains 5% of the user's battery per hour because it's running an idle WebSocket connection is an app that gets uninstalled.
A Diagnostic for Your Feature
If you're trying to decide which tier your feature needs, six questions usually resolve it.
Does lag of 30 seconds feel like a defect? If yes, you might need tier 3. If no, you're probably fine with tier 1 or 2.
Does the feature involve two users interacting with each other in the same moment? (Chat, multiplayer, live collaboration.) If yes, almost certainly tier 3. If no, probably tier 2 or below.
Does the user need to be notified of the change even when the app is closed? If yes, you need at least tier 2 (push notifications). The "real-time" part is more about the notification system than about the in-app update.
Could the user be staring at the screen for minutes, waiting for an update? If yes, you probably want tier 2. They'll notice if it's slow. But tier 3 is overkill unless lag is felt as a defect.
Is this feature most of what the app does, or one of many features? If it's central, the investment in tier 3 is more defensible. If it's one feature among many, tier 1 or 2 is almost always the right answer.
Are there regulatory or financial consequences to lag? (Trading, live auctions, time-sensitive bidding.) If yes, you need tier 3, with the engineering rigor to back it up.
If you answer most of these honestly and the answers point to tier 1 or 2, the buyer's original request for "real-time" should be translated accordingly. The feature still works the way the buyer wanted. It just doesn't cost what tier 3 would have.
How to Have the Conversation Differently
If you're scoping a feature and the word "real-time" came up, here's the conversation to have with your developer.
Don't ask: can we make it real-time?
Ask: which tier of real-time does this feature actually need? Walk through the three options with them. Have them tell you, for your specific feature, which tier matches what the user actually needs.
Then ask: what does each tier cost to build, run, and maintain? The numbers should be different by significant factors. If the developer says they're all roughly the same, you're not getting a real answer.
Then ask: which tier is the rest of our app built to support? This is the question that matters most for an existing app. Adding tier 3 to an app that wasn't designed for it is a much bigger project than adding it to one that was. Knowing the answer changes the conversation entirely.
The broader skill of reading scope and price together — including for features like real-time — is something we cover in how to read a developer's estimate. The real-time question is one of the highest-leverage cases of that skill.
The Honest Close
"Real-time" is the most over-specified word in mobile development. It's used to mean three different things, costing three different amounts, with three different architectural implications. The casual version of the request is almost always over-specified relative to what the user actually needs.
This isn't to say that real-time features are wrong or that nobody should build them. Chat apps need true real-time. Multiplayer games need true real-time. Trading apps need true real-time. For those products, the cost is justified.
But for the dozens of apps where "real-time" got added to the scope without much discussion — the social feeds, the notification systems, the counters, the small updates that the user wouldn't notice if they were 30 seconds late — paying for tier 3 when tier 1 would have worked is one of the most common over-spends in mobile development.
The translation from "should be real-time" to "should be tier 2, with these specific tier 3 exceptions" is one of the highest-value scoping conversations you can have. It saves real money. It produces a faster, cheaper, simpler app. And it doesn't, in most cases, cost the user anything they would actually notice.
You don't need to understand WebSockets. You don't need to know what eventual consistency means at the engineering level. You just need to know that "real-time" is three different products, costing three different amounts, and you should know which one you're buying.
That alone — the willingness to slow down on the word "real-time" and ask one or two follow-up questions — is the difference between a feature that fits your budget and a feature that quietly doubles it.