Every few weeks a founder tells me the same thing: "We just need to add a chatbot to the site. How hard can it be?"
The demo is easy. A weekend, an API key, and a chat bubble. I know, because I designed and built Chatbotz, a SaaS platform where businesses create an AI chatbot and deploy it on any website with a single line of code.
The demo is not the product. The distance between the two is where the real cost lives, and almost nobody prices it before they start. This is the breakdown I wish every founder, CTO, and marketing lead had before approving that "quick" chatbot project.
What I actually built
Chatbotz covers the full product, built solo from the ground up: a marketing site, authentication, an admin dashboard, bot management, a multi-provider AI layer, and the embeddable widget. Each bot has its own system prompt, welcome message, theme color, and online/offline status.
The stack is React 19, TypeScript, and TanStack Start on the frontend, Convex as the database and serverless backend, Clerk for authentication, and Vitest with Testing Library for tests.
The goal was simple: a non-technical user goes from signup to a live chatbot in minutes. Making it feel simple is what made it expensive. Here's where the cost hid.
Cost #1: Flexibility has a price
Chatbotz supports five LLM providers: OpenAI, Groq, OpenRouter, Anthropic, and Gemini, with per-bot model selection and API key management. The reasoning was sound. Teams have different budgets, different quality needs, and strong preferences about which model they trust.
But every provider you add is a new integration to maintain. Each one has its own request format, its own model names, its own rate limits, and its own way of failing. Your abstraction layer has to hide all of that, and it has to keep hiding it as providers change their models and pricing.
There's also a harder question underneath: who pays for the tokens? Right now, the free tier runs on Groq by default, with full provider selection opening up as the platform grows. That's a deliberate cost decision, because an open-ended free tier on a premium model is a way to lose money quickly.
What to do: decide up front who owns the token bill, you or the customer. That one choice shapes your pricing, your free tier, and how much abuse you can afford.
Cost #2: The system prompt is the product
In a no-code chatbot builder, the system prompt is where the quality is decided. And the person writing it is usually not a prompt engineer. It's a shop owner, a marketer, or an agency account manager.
Most of them will write a weak prompt. The bot will then answer questions it shouldn't, invent details the business never approved, or ramble when a short answer would do. To the visitor, that isn't a "bad prompt." It's the company being wrong.
You can't eliminate hallucinations, but you can contain them: sensible defaults, a clear "I don't know" behavior, and an obvious path to a real human for anything involving money, legal, or health.
What to do: write down the five things your chatbot must never say, and test for them before launch.
Cost #3: One line of code, a lot of responsibility
The best part of Chatbotz is also the riskiest. Each bot gets an auto-generated script tag that loads a lightweight widget.js, which renders an iframe pointing to a public chat endpoint. Any website can embed a working chatbot with no backend setup.
The iframe is a deliberate choice. It keeps the widget's styles and scripts isolated from the host site, so the chatbot can't break a customer's layout and their code can't interfere with the chat.
The trade-off is the public endpoint. Anyone can call it, which means you need rate limiting, origin checks, and a way for owners to switch a bot off quickly. Without those, one bad actor can burn through a customer's API budget overnight.
What to do: if you're evaluating a vendor, ask how they protect the public endpoint behind the widget. If they can't answer clearly, that's your answer.
Cost #4: The boring plumbing
Nobody buys a chatbot because of webhook verification. But it's the kind of work that decides whether the product holds together.
Authentication runs through Clerk, and user data is synced to the Convex database in real time through webhooks verified with Svix. When auth state and user records drift apart, you get the worst kind of bug: users who exist in one system and not the other, with support tickets to match. Tests with Vitest and Testing Library keep it stable as features get added.
It's invisible work, and it's a large share of the real effort.
What to do: when someone quotes you a chatbot project, ask what's included beyond the chat window. Auth, billing, admin tools, and tests are where "cheap" quotes quietly cut corners.
So: build or buy?
After building one, here's the framework I'd give a founder.
Buy if the chatbot is a feature of your business. Support deflection, lead capture, and FAQ answers are solved problems. A good vendor has already paid the four costs above, and you're renting the result.
Build if one of these is true:
- The chatbot is the product you sell.
- You need deep integration with your own data or workflows that vendors can't support.
- Privacy or compliance rules mean conversations can't leave your infrastructure.
One more caution: if you need answers grounded in your own documents, that's an extra layer on top of everything above, with its own cost in retrieval quality and content upkeep. Price it separately.
Don't do either yet if you can't name the one metric the chatbot should move. "Better customer experience" isn't a metric. "Cut first-response time on pricing questions by half" is.
For most startups and agencies, the honest answer is: buy first, build later, and only if the data proves you should.
The takeaway
The model is the cheap part. The expensive parts are the ones you don't see in the demo: provider flexibility, prompt quality, a safely embeddable widget, and the plumbing that keeps accounts consistent.
Price those four before you decide. If the numbers still make sense, then build it.