How much does it cost to build an app like WhatsApp in 2026?

An app like WhatsApp costs from $3,000 if you are adding chat to a product you already run, from $20,000 for a standalone cross-platform chat app, and $60,000 or more for a full messaging product with moderation and a back office behind it. The spread is that wide because “an app like WhatsApp” covers everything from a chat screen inside an existing product to a global messaging network. This guide gives you our starting prices, the engineering decisions that move them, and the question that changes a messaging budget more than any feature list: do you build the real-time layer or rent it?

How much does it cost to make a messenger like WhatsApp?

A cross-platform chat app starts at $20,000 and 4 weeks with us. That buys one-to-one and group messaging, media sharing, and push notifications on iOS and Android from one codebase. A messaging product with moderation, an admin panel and a paywall behind it lands closer to $60,000 and 3 to 5 months. WhatsApp itself is not in this table: it is a platform Meta has maintained for over a decade, and no agency estimate describes it.

These are the starting prices from our pricing page, and they are floors rather than quotes. The cheapest row is the one most readers skip: if you already have an app and only need conversations inside it, that is an integration of a hosted chat service rather than a build, which is why it starts at $3,000. Design sits alongside the build: mobile app design starts at $8,000 and 2 weeks, and hourly design, DevOps and technical advice run at $50 an hour. End-to-end encryption is not a line on this list, because it is a multiplier on the whole build rather than a feature you bolt on, and running the product afterwards is a separate line from $1,000 a month. The timelines are first-release timelines; for what fills them phase by phase, see how long app development takes.

Our own published numbers sit inside that band. Buke, a dating app we built with React Native, cost $60,000+ over 5 months for the mobile app, plus $30,000+ over 3 months for the web version we added while the App Store review dragged on. Chat is central to it: text and voice messages, reporting, and a subscription gate on messaging. That is a published cost for a messaging-heavy product, which anchors a budget better than any clone estimate.

“When a founder asks what a messaging app costs, the honest first answer is a question: is chat your product, or a feature of your product? Those are different budgets and different teams. Most people who say ‘an app like WhatsApp’ mean the second one, and they are relieved when they find out how much cheaper that is.”

Roman Surikov, CEO at Ronas IT

What actually drives the cost of a chat app

The chat screen is the cheap part. Rendering a list of messages and a text input is the smallest piece of the job. The budget goes on everything that has to be true around those messages: that they arrive, arrive once, arrive in order, survive a dead connection, and show the same history on a second device. The sections below run in rough order of how often they surprise people.

Message state and delivery receipts

Sent is one state on the sender's side. Delivered and read are tracked per recipient and synced back to every device the sender uses, which is what makes group chats expensive: in a group of 40, one tick stands for 39 separate states. WhatsApp compresses all of it into grey and blue check marks, which is why users assume it is trivial.

Offline behaviour and push notifications

Phones lose signal, sleep, and get killed by the operating system. A message sent on a subway has to queue locally, send once when the connection returns, and not duplicate itself if the user retries. Meanwhile the recipient needs a push notification that survives Doze on Android and the Apple Push Notification service on iOS. Push reliability is a common source of “the app is broken” reports on messaging products, and tuning it is testing work more than coding work.

The message lifecycle: edit, delete, react, reply, forward

Editing, deleting and reacting change a message that has already been delivered, so each change has to reach devices that may be offline and needs a rule for what other people see afterwards. Replies and forwards are cheaper: they are new messages that point at an old one. Deleting is the awkward one: someone may already have read the message, so most apps leave a tombstone rather than rewrite history.

The media pipeline

Photos, video, voice notes and documents each need upload with resume, compression, a thumbnail, storage with a retention policy, and a download path that does not fill the user's phone. Locations, contacts and polls sit in the same attachment menu but are structured payloads rather than files: they cost you sync and rendering, not storage. Media is usually the largest infrastructure line on a messaging product, and the first thing to price properly if you expect video.

Encryption, if you need it

End-to-end encryption is an architecture, not a feature. When the server cannot read messages, it also cannot search them, moderate them, or hand a new device the old history, so key exchange, device verification and multi-device sync all become your problem. WhatsApp exposes a security code screen for exactly this reason. Adding encryption after launch is close to a rebuild, so this is a first-week decision. Regulated products make it harder, though not in the way people assume: data residency, access control and audit logs of who did what all work on ciphertext, so they coexist with end-to-end encryption. What collides with it is a requirement to read the messages themselves, such as supervising or retaining what was said, or producing message bodies when someone asks for them. Whether that applies to your product is a question for your counsel rather than your architect, so design the encryption model and the compliance model together.

Moderation, reporting and the app stores

Both Apple and Google expect a communications app to ship with a way to report and block people, and to act on those reports. That means a back office behind the button. Buke lets users report problems from inside the chat. Its App Store review still took six months for reasons outside the build, and we shipped a React web version while we waited so iOS users were not left behind. Treat review as a phase with its own risk and schedule it like one.

For a stage-by-stage view of how these choices land on an invoice, we broke the same arithmetic down for cross-platform projects in what affects React Native app cost at each stage of development.

Tell us which of these your product needs, and we will price the ones that apply.

Get a project estimate

Build the real-time layer or rent it?

Nothing else on this page moves a messaging budget as much as this choice, and “renting” covers two different products that get talked about as one. A realtime transport such as Pusher Channels is pub/sub delivery and presence, priced by the concurrent connections and daily messages your plan allows; the message store, the history and multi-device sync stay yours to build. A chat platform such as Stream, Sendbird or Twilio Conversations brings the message store and the sync with it, which is how you get working chat in days, and is priced per monthly active user. Building the whole layer yourself starts at $10,000 on our price list, under API development, on top of the app it serves. All three routes are legitimate.

There is a middle route, and Buke is on it. Pusher handles messaging there, while the reporting and the subscription gate around it are ours, and the team spent its time on matching and anonymity instead. Chat is a feature of that product rather than the product itself, and the messages carry no business logic of their own. Lainappi, a Finnish rental marketplace, is the opposite shape: the entire rental flow lives inside the chat. Owners and renters agree terms there, the lease card and the payment button sit in the thread, and system messages walk both sides through payment and pickup. That is business logic in the thread, and a generic chat service would have fought that design rather than saved time on it.

“The question I ask is whether the thread has to know anything about your business. If a message is just a message, rent the layer and spend the saved months on the part nobody else has. The moment a message has to carry a payment state, or unlock a box, or expire when a booking ends, you are building a workflow that happens to look like a chat, and no SDK will hand you that.”

Evgeny Leonov, CTO at Ronas IT

The follow-on effects also differ. A rented layer is an operating expense that scales with your success and a dependency you do not control. A built layer is a team commitment: someone has to keep it alive for as long as the product lives. Neither is free, and picking the wrong one is expensive to reverse, so make this call during scoping rather than during the second sprint.

What WhatsApp changed since we first published this guide

We wrote the first version of this article in 2023 and listed WhatsApp's weak spots as openings for a new app. Meta has since closed two of them, which is a useful lesson in itself.

• Editing messages. In May 2023 WhatsApp added editing within 15 minutes of sending. Our 2023 version called the lack of it a differentiator. It lasted two months.
• Phone numbers as identity. In June 2026 WhatsApp began letting people reserve usernames. The wider rollout comes later in the same year, and that is the point at which someone can find you and message you by handle alone. Hiding your phone number was a selling point for competing messengers for years.

Plan around that. Anything that looks like a gap in WhatsApp today can be a release note next quarter, and you cannot outspend a product with more than 3 billion monthly users on a feature race. What Meta answers slowly is a product shaped around one audience it does not serve.

Where a new messaging app can still win

Every messenger that grew after WhatsApp did it by being different rather than cheaper or more complete. The table below lists angles rather than features to copy.

The pattern that repeats in our own work is narrower than any of those. The messaging products we build are not general-purpose messengers at all: they are chat inside a rental marketplace, or inside a dating app. The audience is already there for another reason, and the chat is what makes the transaction possible. That is a far easier product to launch than a public messenger, because you never have to solve the empty-network problem where nobody joins until their friends are already on it.

If your idea is closer to a feed than a thread, the cost drivers move: storage and ranking replace delivery state and presence. We ran the same exercise for photo sharing in how much it costs to make an app like Instagram.

Which business model fits a messaging app

Monetisation shapes the build, so decide it before scoping rather than after launch. A subscription needs billing, entitlements and store compliance from day one; advertising needs an ad stack and a privacy policy that survives review.

Buke shows the subscription path in practice: messaging is available during a promotional period and to subscribers, so chat is both the product experience and the paywall. That decision reached into the build, because every entry point into a conversation has to check entitlement before it opens.

Do you need WhatsApp's tech stack?

No. WhatsApp built its server side on Erlang with a heavily modified ejabberd, choices its team made early on while optimising for millions of concurrent connections per server. Erlang is excellent at that job and hard to hire for, and you are not solving that problem yet.

We build messaging clients with React Native so one codebase covers iOS and Android, and back them with Laravel or Node.js. Both projects in this article have React Native clients, and Buke runs a Laravel back office behind its app. For the real-time transport you either rent a service or run WebSockets on your own infrastructure, and either is fine at the scale a new product starts at. Pick a stack your team can hire for and maintain, then revisit it when your concurrency numbers make it a real question. We walked through the libraries and the pitfalls in building a chat app with React Native, and the tradeoffs of one codebase versus two on our cross-platform app development page.

How we estimate a messaging app

Our first number is free and rough: describe the product and we come back with a range and the assumptions behind it. When the scope is worth pinning down, the paid analysis phase costs $2,000 to $3,000 and takes 1 to 2 weeks, and produces user stories, flow maps, a feasibility check, and a scope document with a budget and a timeline.

Either number arrives with its gaps named: what we understood the goal to be, what information is still missing, and which requirements are worded too loosely to price. The stack we propose is checked against our own register of technologies rather than picked fresh per project. What you get is a range of hours with the risks that could move it, and a mitigation written next to each one.

Every estimate we send carries a page describing the conditions it holds under: the proposed stack, the expected team shape, and the third-party services it assumes. We started attaching it after reading back through our own recent estimates and finding that the default stack lived in people's heads and on calls, never on paper. It matters most on messaging projects, because “we assumed a hosted chat service” and “we assumed you want end-to-end encryption” are the difference between two budgets that are not close to each other. An estimate is conditional by nature: these hours and this budget, given this stack and this team.

From there the rhythm is predictable. Each sprint runs one to three weeks and ends with something you can open yourself, whether that is a build on a dev server, a screen you can click through, or designs in the mockups. Every week you get a written update on what moved, what it cost in hours, and what comes next. That is the usual flow, and the project manager adapts it to your project. If you want the mechanics of turning a product idea into a number, we wrote them up in how to estimate the development of a website or a mobile app.

What to do next

If you are budgeting a messaging product, work through these in order. Each one narrows the range before you talk to anyone about money.

1. Write one sentence naming the audience WhatsApp serves badly and why they would leave. If you cannot, you have a feature idea rather than a product.
2. Place yourself in the price table above: chat inside a product you already run, a standalone chat app, or a full messaging product with a back office. That sets the budget band.
3. Settle end-to-end encryption now. It reshapes search, moderation and multi-device history, and retrofits are close to a rebuild.
4. Choose rent or build for the real-time layer, and write down why. Rent if the thread carries no business logic; build if it does.
5. Pick the monetisation model before scoping, because subscriptions, ads and in-app purchases each add different work.
6. Cut the first release to the messages, media and notifications, and treat calls, stickers and channels as later releases.
7. Plan store review as a phase with its own risk. A communications app needs reporting and blocking before it is submitted, not after.

Do that and the wide ranges collapse into something you can defend to an investor: a scope, a stack, and a number that follows from both.

Have a messaging product in mind? Send us the scope you have so far and we will tell you what it takes to build it.

Get a project estimate