The gap between marketing and technology in Kenya is not a knowledge gap. It is a framing gap.
Marketers see a problem and reach for a marketing solution. Developers see a system and build for the system.
What is missing is someone who can look at a marketing problem and ask: what is the precise technical solution this requires?
That question is what led me to build my own AI chatbot from scratch. Here is how the thinking worked and why the stack I chose followed directly from the problem I was solving.
The Problem, Precisely Stated
I run AM Digital KE, a Nairobi-based SEO agency. I have over 200 published articles on “how-to” and “what-is” concepts in SEO.
I also have a SEO Resource page specifically for the Kenyan market packed with guides, checklists, quizzes, calculators. Together, they cover everything a Kenyan business owner needs to understand search.
The problem: Even though the content is super easy to read and understand, visitors arrived, found the content overwhelming, and left without finding what they needed.
A chatbot seemed obvious.
But the precise problem was more specific than "we need a chatbot." It was: my audience does not know enough about SEO to self-navigate a content library.
I need something that can teach, remember, and hand off, in that order.
That precision matters. It eliminates half the available solutions before you write a single line of code.
Why an Off-the-Shelf Chatbot Was the Wrong Tool for This Problem
I installed WPChat first. It is a product by Awesome Motive, a company I work with as a content and SEO expert. I understood how it was built and had worked with the team behind it. It is genuinely well-engineered.
But it was built for a different problem.
WPChat runs on a question tree. Predefined questions, structured decision paths. That architecture works perfectly for support flows and booking systems. It does not work when your users do not know what to ask.
Two other technical limitations made it the wrong fit.
- First: it added significant page load overhead. For an SEO agency whose core advice includes page speed optimisation, that was not an acceptable trade-off.
- Second: it had no persistent memory. Every session started from zero. Returning users received no continuity. The entire learning context from their last visit was gone.
I shut it down within weeks.
The Stack - And Why Each Piece Was Chosen
The replacement is built on three tools: n8n, Google Sheets, and Gemini Flash.
n8n handles the entire backend workflow.
Webhook receives the message, triggers the session logic, calls the AI, writes to storage, formats the response.
No custom server required. Self-hosted on a Hostinger VPS, which keeps latency inside the continent. The visual workflow builder meant I could design the logic.
This includes edge cases like returning users, recall sessions, and message count tracking without writing backend code.
Google Sheets is the database for Phase 1(Supabase for Phase 2).
Three tabs: Contacts, Conversations, Articles. Every user gets a UUID session ID on first visit. Every message is logged with a timestamp and role (user or AI).
Topic tags are extracted per message and written back to the Contacts tab. The schema was designed from day one for migration to Supabase in Phase 2.
So it has snake_case column names, ISO datetime strings, no merged cells already set up.
Gemini Flash handles the AI call.
The model returns a strict JSON object with four keys: ai_response, tags, chips, and show_cta.
Enforcing response_format: json_object in the API call was critical without it, the model occasionally returned plain text, which broke the downstream tag extraction logic entirely.
max_tokens is set at 2500 after early testing showed that 1024 was causing mid-sentence truncation, which leaked raw JSON into the chat bubble.
The widget itself is a single HTML file. With CSS, markup, and JavaScript in one IIFE. It injects into WordPress via WPCode. No plugin dependency. No framework overhead.
The UX Decision That Changed Everything
The first version had an open text input. Ask me anything. Users froze. They did not know what was worth asking.
The solution was industry-specific chips. These are clickable topic buttons generated based on the user's industry at the gate.
As a result, a real estate agent sees different options from a restaurant owner. You click, the bot teaches, new chips appear. The blank-page problem disappears.
This is the marketing-technology intersection in practice. The UX decision was not a design decision; it was a decision about what my audience knows. The technical implementation followed from that.
The Principle
Identify the problem precisely. Let the problem choose the stack.
WPChat failed not because it is a bad product, but because it was solving a different problem. n8n, Sheets, and Gemini work not because they are the best tools in abstract, but because they solve this problem specifically.
That is the gap worth closing in Kenya. Not more tools. Better problem statements.
What I Have Learned
I don't just want to be the best SEO company in Kenya. I want to help companies solve real problems for their specific problems.
Yes, I offer a free SEO analysis that helps me understand a business and a business understand their needs.
But I had no proper way to solve super specific problems that clients brought. That is a big reason I taught myself AI automations - to help Kenyan businesses.