How to Build a Mobile App With an AI Chatbot: Scoping, Architecture and Guardrails for Nigerian Business Apps

What an in-app AI chatbot is: three levels

An in-app AI chatbot is a conversational assistant inside your mobile app that uses a language model to understand what the user types and respond in natural language. In practice there are three levels, and the difference between them is what the bot is allowed to know and do:

• Level 1: General or FAQ assistant. Answers common questions from a fixed set of approved answers, optionally using a language model to understand phrasing. Cannot see the user's account. Low risk, low cost.
• Level 2: Knowledge-grounded assistant. Answers from your own documents (policies, product catalogue, help articles, price lists) using retrieval so replies are based on your content rather than the model's memory. Still cannot act.
• Level 3: Agent with tools. Can look up the user's orders, bookings or balance, and perform actions (reschedule, request a refund, renew a plan) through controlled backend functions, with confirmations. Highest value, highest risk and cost.

Most Nigerian business apps should start at Level 2 and add Level 3 tools one at a time, beginning with read-only lookups.

Which level does your app need?

The right level follows from what your customers ask most and what it costs you to answer today.

A useful test: list the last hundred support conversations from WhatsApp and classify each row. The share that falls in the first three rows tells you how much a bot can absorb; the rest tells you how good the handoff must be.

Architecture: the app never talks to the model directly

The single most important rule is that the mobile app sends messages to your backend, and only your backend talks to the AI model. Putting a model provider's API key inside an app means anyone who decompiles it can run up your bill and read your prompts. A sound architecture has these parts:

• App chat screen: message list, input, streaming display of the reply as it arrives, suggested quick replies, and a "talk to a person" button that is always visible.
• Backend chat service: authenticates the user, keeps conversation history, assembles the prompt (instructions, retrieved knowledge, tool definitions, recent messages), calls the model, runs any tool calls, applies guardrails and returns the reply.
• Knowledge store: your documents, chunked and indexed for retrieval (a vector database or a search index).
• Tool layer: a small set of backend functions the model may request (get order status, list appointments, create ticket), each with permission checks tied to the logged-in user.
• Handoff integration: creates a support ticket or opens a WhatsApp conversation with the transcript attached.
• Logging and analytics: every conversation, retrieval, tool call, cost and outcome, with personal data handling defined.

Model choice sits behind this architecture, which means you can switch providers or use a cheaper model for simple turns without changing the app.

Grounding the bot in your business knowledge

Grounding means giving the model your actual content at answer time so that it replies from your policies and catalogue rather than from general knowledge. The common technique is retrieval-augmented generation (RAG): your documents are split into chunks, indexed, and the chunks most relevant to the user's question are inserted into the prompt with an instruction to answer only from them. What to feed it, in order of value for a Nigerian business app:

• Refund, delivery, cancellation and payment policies, including bank-transfer and USSD instructions.
• Product or service catalogue with current prices and availability (synced from the same database the app uses, not a copy that goes stale).
• Delivery zones, fees and timelines by area.
• Frequently asked questions from your WhatsApp history, rewritten as clear answers.
• Account and app how-tos (reset password, update phone number, delete account).

Keep it current with a sync job rather than manual uploads, mark each chunk with its source and date, and instruct the model to say when it does not know and offer a handoff. A bot that confidently invents a price is worse than no bot.

Letting the bot take actions safely

Tool calling is the mechanism by which the model asks your backend to run a function ("get order status for order 4521") and receives the result to use in its reply. It is how a Level 3 bot becomes genuinely useful, and it is where the risk lives. Rules that keep it safe:

1. Start read-only. Order status, appointment lookup, balance and receipts cover most account questions with no risk of unwanted changes.
2. Scope every tool to the logged-in user. The backend, not the model, decides whose data is visible. The model never receives another customer's records.
3. Confirm write actions. Before cancelling, rescheduling or refunding, the bot restates what it will do and asks for a yes; the app can render this as a confirmation card with a button.
4. Set limits. Refunds above a threshold, address changes on dispatched orders, or anything touching money beyond small amounts route to a human.
5. Log every call with inputs, outputs and the conversation ID for audit and dispute resolution.
6. Design for failure. If a tool times out (a slow gateway lookup, say), the bot should say so and offer to notify the user, not guess.

Human handoff: WhatsApp and support tickets

The bot's most important feature is knowing when to stop. Handoff should be triggered by the user asking for a person, by the bot detecting a complaint or an out-of-scope request, by repeated failure to answer, and by any request beyond the tool limits. For Nigerian businesses, two handoff routes work well:

• WhatsApp: open a chat with your business number with a pre-filled reference, or, if you use the WhatsApp Business Platform, create the conversation from the backend and post the transcript summary so the agent starts informed.
• In-app ticket: create a support ticket with the transcript attached, tell the user the expected response time, and notify them through the app's notification system when a reply arrives.

Handoff must carry context. An agent who has to ask "what was the problem again?" wipes out the goodwill the bot built.

Step-by-step: building the chatbot

1. Classify your support conversations and choose the level, the initial tool set (if any) and the handoff route.
2. Write the bot's job description: what it does, what it must never do (promise discounts, give medical or legal advice, discuss competitors), its tone, and the languages it handles. This becomes the system instructions.
3. Assemble and clean the knowledge sources, set up the index and the sync job from your live catalogue and policies.
4. Build the backend chat service with authentication, conversation storage, prompt assembly, retrieval, model call, streaming responses and guardrail checks.
5. Implement the first tools (read-only), with per-user scoping and logging.
6. Build the app chat screen with streaming display, quick replies, confirmation cards and a permanent "talk to a person" option.
7. Wire the handoff to WhatsApp or tickets with transcript context.
8. Create a test set of at least a hundred real questions (including tricky and adversarial ones) with expected answers, and run it before every change.
9. Pilot with staff, then a small customer group, reading transcripts daily and fixing knowledge gaps.
10. Launch with cost alerts, a monthly token budget in US dollars, and a weekly review of unanswered questions and handoff rates.

Guardrails, evaluation and data protection

Guardrails are the checks around the model that keep the bot within its job. Practical measures:

• Instruction discipline: explicit rules in the system prompt, including "answer only from provided knowledge; if unsure, say so and offer a human".
• Input and output checks: detect prompt-injection attempts, filter personal data the bot should not repeat, block topics outside scope.
• Grounded citations: have the bot reference the policy or product it relied on, so staff can trace a wrong answer to a wrong document.
• Rate limits per user to control abuse and cost.
• Evaluation: the test set above, scored for accuracy, refusal when appropriate, and handoff behaviour; track it over time as knowledge and models change.
• Data protection: conversations may contain names, phone numbers, addresses and payment details, which fall under the Nigeria Data Protection Act 2023. Tell users the assistant is automated and that conversations are stored; minimise what is sent to the model provider; check the provider's data-use terms; set retention periods; and confirm obligations with the Nigeria Data Protection Commission. This is not legal advice.

What changes for Nigerian businesses

Five local factors shape the design more than the model choice does.

• Networks and latency. Model replies take seconds; on a weak connection they feel like failure. Stream the reply token by token, show a typing state immediately, keep prompts compact, and let users leave the screen and get a notification when the answer is ready.
• Language and tone. Customers write in English, Pidgin, and mixes with local languages. Current models handle Pidgin reasonably for understanding, but replies should stay in clear English unless you have tested alternatives. Include Nigerian terms (POS, transfer, "I don pay") in your test set.
• Dollar-denominated usage. Model tokens are billed in US dollars per conversation; naira volatility changes the cost per chat month to month. Use a smaller model for routine turns, cache common answers, cap conversation length, and set hard monthly limits.
• Trust. Nigerian customers are wary of automated systems around money. The bot should be honest about being a bot, never ask for OTPs or PINs, and make the human route obvious.
• WhatsApp as the alternative. If most support already happens on WhatsApp, consider whether the assistant should live there instead of, or as well as, in the app. The backend service described here can serve both channels.

Example (hypothetical): a Lagos internet provider's customer app

Example (hypothetical): a Lagos internet service provider with tens of thousands of home and small-office subscribers fields the same questions all day on WhatsApp: "is there an outage in Yaba?", "when does my plan expire?", "how do I renew by transfer?", and "my connection is slow". It builds a Level 3 assistant into its customer app:

• Knowledge: plans and prices, coverage areas, renewal instructions per payment method, troubleshooting steps for common router issues, synced nightly from the support wiki and billing system.
• Read-only tools: get subscription status and expiry; get current outages by area; get last three invoices.
• Write tools with confirmation: create a renewal payment link; open a fault ticket with the user's location and device details.
• Handoff: any conversation mentioning refund, billing dispute or repeated slow-speed complaints creates a ticket and offers WhatsApp with the transcript.
• Guardrails: never promises restoration times unless the outage record includes one; never discusses discounts; rate-limited per subscriber.
• Operations: weekly review of unanswered questions feeds the knowledge base; monthly token spend tracked in dollars with an alert at a set threshold.

The design point is that most value came from three read-only tools and accurate knowledge, not from the model being clever, and that the handoff kept billing disputes with people.

How much does an in-app AI chatbot cost?

The cost depends almost entirely on the level. The figures below are indicative 2026 ranges, consistent with the general AI chatbot bands for Nigeria; actual quotes vary with scope, vendor and exchange rate. Compare two or three written quotations on identical scope and ask for the tool list and knowledge sources to be itemised.

Recurring costs: model usage in US dollars (varies with conversation volume, prompt size and model choice; set a monthly cap), vector database or search hosting, backend hosting (indicatively ₦150,000–₦800,000+ per year on a VPS or cloud), WhatsApp Business Platform messages if used for handoff, and maintenance at roughly 15–25% of build cost per year, which for chatbots also covers knowledge upkeep and model updates. If the chatbot is part of a new app rather than an addition, the overall project usually lands in the indicative medium band (₦5,000,000–₦15,000,000).

Mistakes to avoid

• Calling the model from the app. The key leaks, the bill is unbounded, and you cannot enforce permissions or guardrails.
• Skipping grounding. An ungrounded bot invents prices, policies and delivery times, and customers hold you to them.
• Starting with write actions. Cancellations and refunds by bot before read-only lookups are proven is how you lose money and trust.
• No visible human route. Users trapped with a bot leave one-star reviews and take their complaint to social media.
• No test set. Without a fixed set of real questions you cannot tell whether a change improved or broke the bot.
• Stale knowledge. A manual upload from six months ago will confidently quote old prices; sync from live systems.
• Ignoring dollar costs. A popular bot with long prompts can cost more than the staff it replaced; cap, cache and monitor.
• Pretending it is a person. Disclose that it is automated; it is both honest and, under data protection principles, expected.

Conclusion

An AI chatbot inside a mobile app earns its place when it is scoped to the questions customers actually ask, grounded in your real policies and catalogue, given a small set of carefully permissioned tools, and paired with a handoff that carries context to a person on WhatsApp or a ticket. Put a backend service between the app and the model, start read-only, build a test set, cap dollar spend, and be honest with users that they are talking to software. Build it that way and the bot removes the repetitive half of your support load without creating a new class of complaints. If you are planning an app with an AI assistant and want the scope, knowledge base, tools and handoff designed for how Nigerian customers actually ask for help, Linestech builds AI-enabled mobile apps and chatbots for Nigerian businesses and can help you decide which level to start at.

Frequently asked questions

Which AI model should we use for an in-app chatbot?

Choose the architecture first and the model second. Any current major provider's models can power a Level 2 or 3 assistant; differences lie in cost per token, latency, tool-calling quality and data-use terms. Keep the model behind your backend so you can switch or mix models (a cheaper one for routine turns) without changing the app.

Can the chatbot check a customer's order or balance?

Yes, through tool calling: the backend exposes a function such as "get order status" that the model may request, scoped to the logged-in user. The model never accesses the database directly; your backend runs the function with permission checks and returns the result for the reply.

Will the bot understand Pidgin and mixed-language messages?

Current models generally understand Nigerian Pidgin and common mixed phrasing well enough for support questions, but performance varies and slang shifts. Include Pidgin and local terms in your test set, and keep replies in clear English unless you have tested other languages with real customers.

How do we stop the bot from making things up?

Ground it in your own documents with retrieval, instruct it to answer only from provided knowledge and to say when it does not know, have it cite the source it used, run a fixed test set before each change, and review transcripts weekly. Grounding plus honest refusal removes most invented answers; the rest is caught by review.

Should the assistant be in the app or on WhatsApp?

If customers already contact you on WhatsApp, an assistant there may reach more people; an in-app assistant can use the logged-in session for account actions without extra verification. Many Nigerian businesses do both, with one backend service behind both channels and the same knowledge and tools.

What happens to customer data sent to the AI provider?

It leaves your system and is processed under the provider's terms. Send the minimum needed, avoid sending payment details or identity documents, check whether the provider uses data for training and for how long it is retained, disclose the processing in your privacy notice, and confirm your obligations under the Nigeria Data Protection Act 2023 with the Nigeria Data Protection Commission.

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)
• WhatsApp Business Platform — Meta for Developers
• Node.js documentation
• PostgreSQL documentation
• OpenAI platform documentation
• Anthropic developer documentation