Service · AI Chatbots
AI Chatbot Development
Answers grounded in your data, with rate limits and a spend ceiling from day one.
A chatbot is easy to demo and easy to get wrong in public. It has to answer from your actual content, refuse what it does not know, hand off to a person cleanly, and survive being pointed at by a stranger with a script. There is one running on this site right now, hardened exactly that way, and you can open it and try to break it.
If a chatbot vendor cannot tell you their per-IP rate limit and their daily spend cap, they have not shipped a public chatbot, they have shipped a liability.
TL;DR
- AI chatbot development for customer support automation, lead qualification, and in-product help, grounded in your own documentation.
- The chatbot on this site is the reference build: OpenAI gpt-4o-mini behind a server-side system prompt, Upstash Redis rate limiting at 10 requests per minute per IP, 50 per day per IP, and 2,000 per day globally.
- It also caps messages at 2,000 characters and sends only the last 10 messages as context, so cost per conversation has a hard ceiling.
- ScamMinder ships a Telegram bot for running domain checks from chat, on top of a 14-phase pipeline with GPT-4o classification across 20,000+ domains.
- Most engagements start around $5K; smaller well-scoped work is considered case-by-case. MVPs typically take 3–6 weeks; larger, complex platforms are scoped individually.
The challenge
Public chatbots fail in two directions. The first is cost: no per-IP rate limit, no daily ceiling, no message length cap, and then one scripted visitor discovers the endpoint and your model bill becomes an incident. The second is accuracy: the bot is handed a vague system prompt and no grounding, so it answers questions about your refund policy by inventing one, and the screenshot ends up somewhere you cannot delete it. Underneath both sits the same root cause, which is treating the chatbot as a UI feature rather than a public API you are exposing to strangers with a language model attached. A serious build starts from the opposite assumption: assume abuse, assume the prompt will be probed, assume the retrieval will sometimes return nothing useful, and decide in advance what the bot does in each of those cases. That work is not visible in a demo, which is exactly why it gets skipped.
What I build
Support Chatbot Build
Grounded answers from your documentation and product data, with refusal behavior and a clean handoff to a human
Rate Limiting & Cost Control
Per-IP and global limits in Redis, message length caps, bounded context windows, and spend alerts before the invoice
Retrieval & Knowledge Base
Ingestion, chunking, embeddings, hybrid search, and re-ranking so answers come from your content rather than the model's memory
Multi-Channel Delivery
One answer engine behind thin adapters for a website widget, Telegram, WhatsApp, or Slack
Lead Capture & CRM Handoff
Qualifying questions, structured capture, and conversations pushed into the CRM or inbox your team already watches
Evaluation & Transcript Review
An evaluation set built from real questions, plus deflection and escalation metrics reviewed against transcripts
What does a production chatbot need that a demo does not?
Four things a demo never shows: a rate limit so one visitor cannot drain your budget, a global daily cap so a bad day has a known cost, grounding in your real content so answers are not invented, and an escalation path to a human. Everything else is presentation.
The chatbot on this site implements all four, and its numbers are not marketing copy. Requests are limited to 10 per minute and 50 per day per IP through Upstash Redis, with a 2,000 request per day global ceiling that stops the whole feature before it can become an unexpected bill. Individual messages are capped at 2,000 characters, and only the last 10 messages travel with each request, which bounds context growth on long conversations.
The system prompt lives on the server, never in the browser bundle, so it cannot be read or overwritten from the client. That single decision separates a chatbot you can put on a public marketing site from one that gets screenshotted on social media doing something it should not.
How do you keep a chatbot from confidently making things up?
Ground it. Retrieve from your documentation, product data, or knowledge base before generating, keep the answer inside what was retrieved, and let it say it does not know. Then build an evaluation set from real customer questions so you can tell whether a prompt change improved accuracy or just moved the failure.
Retrieval quality sets the ceiling on answer quality, so the unglamorous work is in ingestion: chunking tuned to your document type, embeddings, hybrid search combining vector and keyword, and re-ranking before anything reaches the model. Skipping that and stuffing everything into one prompt works fine at ten documents and falls apart at a thousand.
Refusal is a feature. A support bot that answers 70% of questions well and cleanly escalates the rest is worth more than one that answers everything with the same tone of certainty. Escalation should carry the transcript with it, so the person picking up the conversation is not asking the customer to repeat themselves.
Which channel should your chatbot live on?
Whichever one your customers already use. A website widget is fastest to ship and fully under your control. Telegram suits technical and international audiences. WhatsApp reaches the widest consumer base but adds Meta verification and template approval. Slack fits internal tools. The engine stays the same; the delivery layer changes.
ScamMinder is the shipped multi-channel case. The same 14-phase verification pipeline, which has analyzed 20,000+ domains with sub-6-second analysis and 99.9% uptime, is reachable through the web app, a Chrome extension, and a Telegram bot. Building the answer engine once and attaching thin channel adapters is why adding a surface later is cheap.
Straight answer on WhatsApp and Slack: I have not shipped a bot on either. I know the WhatsApp Business API model — business verification, the 24-hour customer service window, pre-approved templates outside it — and the integration work is well within reach, but you should hear that it would be a first for me rather than find out later.
What does chatbot support automation actually save?
It removes the repetitive tier-one volume: hours, availability, order status, policy questions, the same five things asked every day. It does not remove your support team. The measurable win is deflection rate on those specific questions, and you should insist on measuring it rather than accepting a general claim about efficiency.
Adjacent proof from a different modality: the hospitality SaaS I built automates 400 bookings per month across 5 restaurants and cut manual workload by 80% for those flows. That gain came from automating one well-understood, high-volume task end to end, not from a general assistant. Chatbot projects that pick a narrow lane succeed for the same reason.
Start by reading a month of your actual support tickets and counting which questions repeat. That list, not a feature comparison between vendors, is the specification. If the top five questions are not answerable from documents you already have, the first task is writing them down, and no model fixes that for you.
Chatbot channels, with an honest receipt column
Qualitative comparison of delivery surfaces. The last column states plainly whether I have shipped on that channel.
| Channel | Best for | What it costs to run | Shipped by me? |
|---|---|---|---|
| Website widget | Pre-sales questions and documentation search | Model tokens plus abuse protection you must build | Yes — the chatbot on this site |
| Telegram bot | Technical and international audiences, quick utility checks | Low; bot API is free and straightforward | Yes — ScamMinder domain checks |
| WhatsApp Business API | Consumer support at scale in mobile-first markets | Meta verification, template approval, per-conversation fees | No — capability, not a receipt |
| Slack or Teams bot | Internal knowledge search and ops assistants | Low run cost; effort sits in permissions and data access | No — capability, not a receipt |
| In-product assistant | Guiding users through the app they are already in | Highest build cost, highest conversion impact | Partial — booking automation in a hospitality SaaS |
Tech stack
Which of my builds proves this
The clearest receipt for this page is the chatbot running on this site: server-side system prompt, gpt-4o-mini, Redis rate limiting, and a global daily cap. Open it and try to break it. The projects below cover the shipped Telegram bot and the booking automation. WhatsApp and Slack bots are capability, not receipts, and are marked that way in the table above.
ScamMinder — Telegram Bot & AI Pipeline
A Telegram bot for running domain checks from chat, sharing one 14-phase pipeline with the web app and Chrome extension: 20,000+ domains analyzed, sub-6s analysis, 99.9% uptime.
Read case study →Hospitality SaaS — Booking Automation
AI-assisted booking automation across 5 restaurants: 400 bookings automated per month and an 80% reduction in manual workload, with real-time updates over WebSocket.
Read case study →Related services
RAG & LLM Development
The retrieval layer that decides whether your chatbot's answers are grounded or guessed.
Explore →AI Agents
When answering is not enough and the system needs to take actions in your tools.
Explore →Voice AI Agents
The same conversation on the phone, with a page that states plainly what is unproven.
Explore →How we work
Most MVPs ship in 3–6 weeks; complex platforms are scoped individually once the requirements are clear.
Intro Call
A 30-minute conversation about your project, goals, and timeline. No commitment either way.
Scoped Proposal
A written scope, architecture outline, and quote. I respond to every message within 24 hours.
Weekly Demos
You see working software every week, with written progress updates in between. No black boxes.
Ship & Handover
Deployment, documentation, and a clean handover — you own everything I build.
Compliance & standards
Frequently asked questions
Can I see a chatbot you have actually shipped?
How do you stop a public chatbot from running up a huge bill?
Can you build a WhatsApp AI chatbot?
Will a chatbot replace our support team?
How long does a chatbot project take and what does it cost?
Ready to start?
Book a free 30-minute call. No sales pitch — just a direct conversation about your project.
Book Free CallOr email: contact@waseemahmad.dev