What to look for when hiring a WhatsApp bot developer

If you are asking what should I look for when hiring someone to build a WhatsApp bot, the honest answer is: more than most business owners think to check. A bot that collapses under load, fails to process M-Pesa payments, or gets your business account flagged by Meta for policy violations does not just waste your budget. It damages customer trust and can cause service outages, payment reconciliation work, and account remediation that may take days or weeks to resolve. For a Kenyan business owner ready to spend real money on this kind of tool, the difference between a good outcome and a painful one usually comes down to what you know before the conversation starts.

Developers who have shipped production WhatsApp bots think differently from those who have only built demos. A developer who has handled a bot processing tens of thousands of real events, across real users, with real payment flows, has already solved problems that never appear in a tutorial. Treat that kind of production track record as your credibility threshold. This article gives you a practical checklist so you can evaluate any WhatsApp chatbot developer or agency with confidence, ask the right questions, read portfolios correctly, and avoid costly mistakes before you sign anything.

What should I look for when hiring someone to build a WhatsApp bot, the technical baseline

Before you discuss timelines or pricing, you need to confirm that the developer can actually build what you need. There is a significant gap between someone who can connect to the WhatsApp Business API using a no-code platform and someone who has built a production system from the ground up. Understanding that gap protects your budget.

Meta WhatsApp Cloud API experience is not optional

Hands-on Cloud API experience means more than "I have used WhatsApp's API." It means configuring a WhatsApp Business Account (WABA), managing phone number registration, building webhook handlers with HMAC-SHA256 signature verification, and creating HSM message templates that actually pass Meta's approval process. A developer who has only worked with platforms like Wati or ManyChat may not have performed these low-level Cloud API tasks; those platforms abstract the API away entirely and can leave the developer without the underlying skills needed for a custom build.

Ask any candidate to walk you through a webhook they have built, not describe one in theory. If they cannot explain how they verify that incoming messages are genuinely from Meta, how they handle rate limit errors, or what happens when a template is rejected, treat those as signals to probe much further before you proceed.

AI integration and workflow automation skills

A WhatsApp AI bot without solid automation behind it is just a fancy FAQ. The developer must have shipped integrations with OpenAI or another LLM, and they must understand how to manage conversation state across multi-turn dialogues. Session state does not persist automatically in WhatsApp; without an external storage layer such as Redis or PostgreSQL to maintain multi-turn context, you end up with a bot that loses track of where the conversation is two or three messages in.

Ask specifically which automation tools they have used in production. n8n and Make are both widely used choices for chatbot integration with WhatsApp workflows, but developers with n8n self-hosting experience can bring added value because it removes recurring platform licence costs. If they have only used hosted plans without understanding the underlying workflow logic, that limits how they will architect your system, and those architectural decisions compound over time. A developer who has never self-hosted an automation layer will tend to design around the constraints of hosted plans, which means ongoing costs and reduced flexibility for you.

How to read a WhatsApp bot developer's portfolio the right way

Most portfolios show screenshots. Screenshots tell you almost nothing useful. What you need is evidence of a bot that has survived contact with real users: unexpected inputs, failed payment callbacks, API outages, and edge cases that no brief ever anticipates. Knowing how to interrogate a portfolio rather than simply admire it will save you significant trouble. Technical vetting alone is not enough, you need to see what a developer actually delivers under production conditions before you can trust their estimates.

The difference between a live product and a demo bot

A demo bot works when everything goes right. A live product survives rate limit errors, mid-session payment failures, and Meta API disruptions without losing the user or breaking the flow. Ask for links to live products that real businesses use daily. Ask about their error logging setup, how fallbacks work when the AI misunderstands a query, and whether they have monitoring in place for message delivery failures. A developer who cannot answer these questions has not operated a bot under real conditions.

Using production volume as your benchmark

Many experienced teams use production event volumes in the tens of thousands as a useful indicator of real-world capability. A developer with a bot that has processed 50,000 or more events in production has likely encountered and solved problems that simply do not appear at smaller scale, think webhook retry storms, session state corruption at peak load, and edge cases in M-Pesa callback handling. Treat that volume range as your minimum credibility threshold; anything significantly below it warrants a detailed explanation from the developer about the complexity of the flows they did handle.

To give you a concrete point of reference: Alvine Otieno, a Kisumu-based WhatsApp bot developer, has five live products used by real businesses daily, with one bot alone reported to have handled over 50,000 events. If a developer cannot give you a production volume figure, their portfolio remains unverified, regardless of how polished the screenshots look.

Local market knowledge: what to look for when hiring a WhatsApp bot developer in Kenya

Technical skill without local context creates gaps that kill user adoption. A bot built by someone who does not understand M-Pesa flows, low-bandwidth behaviour, or Kenyan data protection law will create problems that no amount of debugging can fix after launch. For any business serving Kenyan customers, this knowledge is not a bonus, it is a prerequisite.

M-Pesa and payment integration capability

A WhatsApp bot for a Kenyan business that cannot handle M-Pesa is not a business tool. Verify that the developer has direct, hands-on experience with the M-Pesa Daraja API: STK push flows, OAuth token management, payment confirmation callbacks, and error handling for failed or stuck transactions. For businesses that handle cross-border payments, Flutterwave integration is worth asking about as a secondary option. Ask them to walk you through a payment flow they have built end-to-end, specifically what happens when the payment gateway returns an error mid-conversation. A developer who has only read the Daraja documentation will struggle to answer this clearly.

Compliance with the Kenya Data Protection Act and WhatsApp policy

Any bot collecting names, phone numbers, or transaction data from Kenyan users falls under the Kenya Data Protection Act 2019. The developer must understand consent capture, data minimisation, and breach notification timelines, the Act requires notification to the Office of the Data Protection Commissioner (ODPC) within 72 hours of a confirmed breach. They must also understand the requirement to register as a Data Controller or Processor if processing personal data at scale. On the WhatsApp side, they must know the rules around opt-in consent for template messages, opt-out handling, and the 24-hour session window. Non-compliance with either framework creates liability for your business, not just the developer's. A developer who is unfamiliar with these requirements is not ready to build a production bot for a Kenyan audience.

Questions to ask before you sign anything

Going into a hiring conversation without prepared questions is how you end up impressed by confident-sounding answers that reveal nothing. Split your questions into two categories: technical vetting and commercial terms. Both matter equally.

Technical questions that reveal real capability

Ask these in your first technical conversation and listen carefully to the specifics:

• How do you secure your webhook endpoints and verify that messages are genuinely from Meta?
• How do you maintain conversation context across multiple user turns?
• What happens when your bot does not understand a user's input?
• How do you handle WhatsApp's 24-hour messaging window for outbound messages?
• Which hosting setup do you recommend and why?

Strong answers reference HMAC-SHA256 verification, Redis or a similar tool for session state, clearly defined fallback flows, a template message strategy for outbound communication, and a reasoned hosting recommendation. Vague answers are a signal to probe further before you move to pricing.

WhatsApp bot pricing, timelines, and post-launch support

Realistic setup costs for a WhatsApp bot with AI and M-Pesa integration typically sit between $1,000 and $3,500, with monthly operating costs of $30 to $200 depending on conversation volume and hosting choices. A basic bot without integrations should be deliverable in three to five days; a conversational AI developer building a full AI agent with CRM and M-Pesa integrations will typically need two to three weeks including thorough testing. These are indicative benchmarks rather than guarantees. What matters is whether the developer can justify their timeline with a concrete delivery plan.

Ask explicitly what is included after launch: bug fixes, Meta policy update handling, monitoring, and template management. A developer with no post-launch support offer is handing you a product with no warranty. Maintenance typically costs an additional $30 to $80 per month for ongoing support, and that cost is worth building into your budget from the start.

Red flags that reveal a developer is not the right fit

Knowing what bad looks like is as important as knowing what good looks like. Some red flags only become visible when you ask the right questions. Others appear in the very first conversation if you know what to listen for.

Warning signs in their answers and communication

Walk away or probe much harder when you encounter these:

• They cannot explain how they handle fallback responses or escalation to a human agent.
• Their portfolio contains only screenshots or sandbox demos with no production evidence.
• They describe WhatsApp bots as if they work the same way as a web chat widget, ignoring session limits and template rules.
• They have no plan for conversation analytics or post-launch optimisation.
• They cannot name the Meta WhatsApp Cloud API and refer only to "the WhatsApp API" without specifics.

Pricing and scope red flags

A quote with no breakdown is a quote designed to change later. A developer who offers a fixed price without scoping the number of conversation flows, integrations, and testing cycles is either inexperienced or planning to add costs once the project is underway. Both outcomes are costly for you. Similarly, if they quote a timeline under one week for a bot that includes M-Pesa integration and OpenAI, ask for a detailed delivery plan with specific milestones. Speed without structure produces technical debt you will be managing for months after the launch.

Make the right choice before the project starts

When you ask what should I look for when hiring someone to build a WhatsApp bot, the checklist comes down to five things: technical skills grounded in real Cloud API experience, a portfolio with verifiable production volume, local payment and compliance knowledge that fits the Kenyan market, honest answers to specific technical questions, and no red flags in communication or pricing. None of these require you to be a developer yourself. They require you to ask the right questions and listen for specific, detailed answers.

The market for WhatsApp Business API developers in Kenya is growing, and so is the range in quality. The gap between a developer who has shipped production-ready software and one who is still learning on your budget remains wide. When you know what to look for before the conversation starts, you protect your investment and sharply improve your odds of launching a bot that earns its cost. If you want a concrete benchmark for what a developer who meets all these criteria looks like in practice, Alvine Otieno's work is a useful starting point for your evaluation.