How to Build a Mobile App With Real-Time Chat: In-App Messaging for Nigerian Business Apps

When does a business app need in-app chat?

In-app chat is worth building when the conversation is part of a transaction that the app must control or record; it is not worth building when customers simply want to ask a question, because WhatsApp already does that better. Use this framework:

Two further tests: would a dispute ever need the transcript as evidence, and does the business lose money when the conversation leaves the app? If either is yes, build it. If both are no, a click-to-WhatsApp button will serve your customers better and cost almost nothing.

How real-time chat works: the components

Real-time chat inside an app is a pipeline rather than a single screen. The moving parts are:

• Transport: a persistent connection (WebSocket or a managed real-time database) that pushes new messages to connected devices within a second or so.
• Message store: conversations, participants, messages, timestamps and delivery states, kept on a server so history survives reinstalls.
• Presence and typing indicators: optional signals showing who is online or typing; useful, but each one adds traffic.
• Media handling: photos, voice notes and documents uploaded to object storage, compressed on the device first, and referenced from messages.
• Push notifications: when the app is closed or backgrounded, the transport cannot deliver, so a push (via Firebase Cloud Messaging and Apple Push Notification service) wakes the user.
• Moderation and reporting: blocking, reporting, keyword filters and, where needed, human review tools in the admin dashboard.
• Access control: who may message whom, for how long, and what happens when an order or session closes.

The difference between a chat feature and a chat product is that in a business app, access control is tied to a transaction: a rider can message a customer only while the delivery is active, and a buyer can message a seller only about a listing.

Build options compared: Firebase, WebSockets or a chat SDK

There are three practical ways to get the transport and message store. Each is used successfully by Nigerian apps; the choice depends on scale, budget currency and how unusual your requirements are.

A pragmatic rule for Nigerian SMEs: start with a managed database or a chat SDK, encapsulate chat behind your own API so the rest of the app does not depend on the vendor, and revisit self-hosting only if volume or cost demands it.

Designing chat for a business app

Scope decides cost. The following checklist covers what a business-app chat usually needs; strike out what your use case does not require.

• Conversation types: one-to-one tied to an order or listing; support conversation with a business account; group chat only if essential.
• Message types: text, photo, voice note, document, location pin, and structured messages (a quote, an order card) that the app renders specially.
• Delivery states: sent, delivered, read; with clear icons. Customers expect WhatsApp-style ticks.
• Unread counts and conversation list ordering by latest activity.
• Push notifications with sender name and message preview, respecting a per-user mute setting.
• Conversation lifecycle: opens when a transaction starts, becomes read-only when it closes, archived after a set period.
• Contact protection: mask phone numbers; offer an in-app call or a masked call instead of exposing numbers where safety matters.
• Block and report, with a queue in the admin dashboard.
• Search within a conversation (server-side if history is long).
• Export or hand-off: a support agent can open the transcript from the order screen.

Features to leave out of a first release unless the business depends on them: end-to-end encryption (complex, and it prevents the moderation and dispute review a marketplace needs), video calling, message editing, reactions, and stickers.

Step-by-step: implementing real-time chat

1. Write the access rules first. For each conversation type, define who can start it, who can join, when it closes, and who at the business can view it. These rules drive the data model and the security configuration.
2. Choose the transport option using the comparison above, and confirm its pricing currency and free tier.
3. Design the data model: conversations (type, participants, linked order or listing, status), messages (sender, type, body or media reference, created time, delivery state), and per-user conversation metadata (unread count, muted, last read).
4. Build media upload with device-side compression, size limits, and storage on an object store or the vendor's CDN; generate thumbnails for images.
5. Implement the chat UI with a message list that loads history in pages, an input bar, attachment picker, and delivery state icons; use the vendor's UI kit if available and restyle it.
6. Wire push notifications so a message to a backgrounded user triggers a push that deep-links into the conversation; suppress pushes when the user is already viewing that conversation.
7. Add moderation: block, report, keyword filters for phone numbers and bank details if you are preventing off-platform deals, and an admin review queue.
8. Handle offline and reconnection as described below, and test it on real Nigerian networks.
9. Set retention and export rules, then document them in the privacy policy.
10. Load-test before launch: simulate hundreds of concurrent conversations, including large image uploads, and watch costs on the vendor dashboard.

Reliability on Nigerian networks

Real-time chat behaves very differently on a congested 4G connection in Lagos traffic or on 3G in a smaller town than in a demo on office Wi-Fi. Design for the network you have:

• Optimistic sending with local queueing. Show the message immediately with a "sending" state, store it locally, and retry until the server acknowledges it. Users should be able to write several messages offline and have them send in order when the connection returns.
• Idempotent message IDs. Generate the message ID on the device so a retried send does not create duplicates.
• Server-side ordering. Use server timestamps for ordering; device clocks are unreliable.
• Reconnection with backoff. Persistent connections drop constantly on mobile; the client must reconnect quietly and fetch anything it missed.
• Compress media aggressively. A 4 MB photo on a data plan is a cost to the customer and a slow send; compress to a few hundred kilobytes and let users request full resolution.
• Small payloads. Avoid sending presence or typing indicators at high frequency; they consume data and battery.
• Push as backup, not the primary channel. If the socket is down, the push notification still tells the user something arrived.

Safety, moderation and data protection

In-app chat creates a store of personal conversations, which brings obligations.

• Nigeria Data Protection Act 2023. Messages, media and metadata are personal data. Define a lawful purpose, a retention period, and a deletion process, and state them in your privacy policy. Confirm your obligations with the Nigeria Data Protection Commission's current guidance.
• Where data lives. Managed chat vendors host abroad. That is common and generally workable, but document it and check any sector-specific rules (health and finance in particular).
• Staff access. Limit who can read conversations, log every access, and never let support view chats without a linked ticket or dispute.
• User safety. Block and report must be one tap away; harassment and scam patterns (requests to move to WhatsApp and pay by transfer outside the app) need filters and review.
• Minors. Education and community apps with young users need stricter controls and parental consent where applicable.
• Sensitive sectors. Telehealth chats may need longer retention for medical records and stricter access; seek professional advice.

What changes for Nigerian businesses

The design choices above are shaped by five Nigerian realities.

• WhatsApp is the benchmark. Customers compare your chat to WhatsApp's speed and ticks. Anything slower or less clear will be abandoned in favour of "just call me on WhatsApp", so either match the basics or offer WhatsApp instead.
• Off-platform leakage is the main commercial risk. On marketplaces, buyers and sellers swap phone numbers to avoid fees. Chat that masks numbers, keeps quotes and payments in-app, and gently filters contact details is how you protect revenue.
• Data costs are real. Design for low data use: compressed media, lazy-loaded history, minimal background traffic.
• Dollar-priced vendors. Chat SDKs and managed databases bill in US dollars per user or per operation. A growing Nigerian user base can turn a small monthly bill into a large one after a currency move; model it and set alerts.
• Trust and records. Nigerian buyers want proof. A transcript attached to an order settles "you said it would arrive on Tuesday" disputes in seconds.

Example (hypothetical): a Lagos home-services marketplace

Example (hypothetical): a Lagos marketplace connects homeowners with plumbers, electricians and cleaners. Early on, it used a "Contact on WhatsApp" button. Within months, most jobs were being arranged and paid off-platform, disputes had no record, and the marketplace earned nothing on repeat work. The team adds in-app chat with these choices:

• A chat SDK for transport and UI, wrapped behind the marketplace's own API so it can be swapped later; conversations are created only from a job request.
• Phone numbers are masked; the SDK's keyword filters flag messages containing phone numbers or bank account patterns and nudge users to "request a quote" in-app instead.
• Quotes are structured messages: the artisan sends an amount, the homeowner accepts, and payment happens in-app; the transcript is attached to the job for disputes.
• Media is compressed on the device; voice notes are capped at one minute because artisans prefer them to typing.
• Push notifications deep-link to the job; conversations become read-only seven days after the job closes.

The measurable goal was to keep quoting and payment inside the app; the chat feature exists to serve that goal, not for its own sake.

How much does in-app chat cost?

Chat is a substantial module. The figures below are indicative 2026 ranges; actual quotes vary with scope, vendor and exchange rate. Compare two or three written quotations on identical scope and check what each vendor assumes about the transport option.

Recurring costs: managed database or chat SDK usage priced in US dollars (per monthly active user or per operation, usually with a free tier; verify current pricing), media storage and bandwidth, push notification infrastructure (typically free at moderate volumes), and maintenance at roughly 15–25% of the module's build cost per year. Within the overall indicative bands for Nigerian apps, a marketplace or telehealth app with chat, payments and an admin dashboard sits in the medium to complex range (₦5,000,000–₦15,000,000 and above).

Mistakes to avoid

• Building chat because it seems expected. If a WhatsApp link serves the customer better, use it and spend the budget elsewhere.
• Storing messages only on the device or in an unsecured database. History is lost on reinstall, and open database rules leak conversations.
• No offline queue. Messages fail silently on weak networks and users assume the app is broken.
• Exposing phone numbers in a marketplace. It invites off-platform deals and safety issues.
• Adding end-to-end encryption to a marketplace or support chat. It blocks the moderation and dispute review the business depends on. Reserve it for cases with a genuine need.
• Ignoring vendor costs until the bill arrives. Set usage alerts in dollars and review monthly.
• Uncompressed media. Slow, expensive for customers, and a storage bill for you.
• No retention policy. Indefinite storage of personal conversations is a compliance and security liability.

Conclusion

Real-time chat belongs in a mobile app when the conversation is part of a transaction the business must control or record. Buy the transport (a managed database or a chat SDK) unless scale or data rules force self-hosting, wrap it behind your own API, tie every conversation to an order or listing with clear access rules, design for weak networks with offline queues and compressed media, and put moderation and retention in from the start. Compare it honestly with a WhatsApp handoff before committing, because the best chat feature is the one your customers actually use. If you are deciding whether your app needs in-app messaging, or how to build it so it survives Nigerian networks and protects your revenue, Linestech designs and builds mobile apps with real-time features for Nigerian businesses and can help you scope the right approach.

Frequently asked questions

Is Firebase good enough for chat in a business app?

For small to medium apps, yes. Firestore or the Realtime Database handles live sync well, and many Nigerian apps run chat on it. You will build delivery states, moderation, masking and search yourself, and usage is billed in US dollars. Encapsulate it behind your own API so you can move later if costs or requirements change.

Should I use WhatsApp instead of building chat?

If conversations are simple enquiries and you do not need a record inside the app, a click-to-WhatsApp button is cheaper and more familiar to Nigerian customers. Build in-app chat when the conversation is part of a transaction you need to control, record or monetise, such as marketplace negotiations, deliveries or clinical consultations.

How do messages arrive when the app is closed?

Through push notifications. Your backend or chat vendor sends a push via Firebase Cloud Messaging (Android) and Apple Push Notification service (iOS) when a message arrives for a user who is not connected. The push wakes the user and deep-links to the conversation; the app then syncs the full message history.

Can staff read customer conversations?

Only if you design it that way, and you should limit it. Give support access to transcripts linked to a ticket or dispute, log every access, and state in your privacy policy that conversations may be reviewed for safety and dispute resolution. Uncontrolled staff access is a data protection risk.

How long should we keep chat history?

Long enough to resolve disputes and meet any sector rules, then delete or anonymise. Many marketplaces keep transcripts for a defined period after an order closes; health and finance apps may need longer under their own regulations. Write the policy down and build deletion into the system.

Do we need end-to-end encryption?

Usually not for a business app. End-to-end encryption prevents the business from reading messages, which blocks moderation, dispute handling and support. Use transport encryption (HTTPS and secure WebSockets) and encrypted storage, and reserve end-to-end encryption for products where private messaging is the purpose.

Sources and further reading

Figures, platform rules and regulations change. These are the primary references behind this article and the places to check before you act on it.

• Nigeria Data Protection Commission (NDPC)
• Firebase documentation
• Node.js documentation
• PostgreSQL documentation
• OWASP Top 10
• Baymard Institute e-commerce UX research