Guides / How to build

How to Build an AI Chatbot App: Keys, Prompts, Costs and Safety

How to build your own AI chatbot app: choosing an LLM provider, keeping API keys safe, writing the system prompt, controlling costs and adding guardrails.

Mythex Team · 2026-09-29 · 8 min read

To build an AI chatbot app you need four things: a chat interface, a small server that holds your model provider's API key and forwards messages to it, a system prompt that tells the model who it is and what it may do, and limits that keep costs and misuse under control. An AI app builder can write all of that from a description. The work that stays with you is choosing the provider, writing the instructions and deciding what the bot must never do.

What an AI chatbot app is made of

Most chatbot apps, whether a support assistant, a tutor or an internal "ask our docs" tool, have the same parts:

The server route is the part people most often get wrong. If the chat page calls the provider directly from the browser, anyone can open the developer tools, copy your key and run up your bill.

Decisions to make before you build

Which provider and model

The main providers (OpenAI, Anthropic, Google and others) all offer a chat-style API that works the same way: you send a list of messages and get a reply. The practical choice is less about the brand and more about the model size:

• Smaller, faster models are cheaper and quick to respond. They are fine for short answers, classification and simple FAQ bots.
• Larger models reason better, follow long instructions more reliably and handle messy questions, but cost more per message and respond more slowly.

Start with a mid-sized model, test it against your real questions, and move up or down from there. If you're new to how these APIs are priced and called, read how to use LLM APIs first.

Where the bot's knowledge comes from

Start with the simplest option that covers your content. Retrieval adds a search index, a way to keep it updated and more places for answers to go wrong. Many useful bots never need it.

Public, or behind a login

A public chatbot on your website is easy to reach but also easy to abuse: someone can script thousands of messages against it. A logged-in chatbot lets you save history per user and set a daily allowance per account. If it's public, cap message length, limit how many messages one visitor can send in a given period, and set a hard monthly limit in the provider's dashboard. How to add login to your app covers the account side.

Whether to save conversations

Saved threads are useful: users can pick up where they left off, and you can read real questions to improve the prompt. They are also personal data. Decide how long you keep them, say so in your privacy notice, and don't save anything you don't need.

Write the system prompt like a job description

The system prompt is the instruction the model receives before every conversation. A good one reads like a short brief for a new employee:

• Role and audience: "You are the help assistant for Oakline, a bike repair shop. You talk to customers."
• Scope: "Answer questions about services, prices, opening hours and booking. For anything else, say you can only help with the shop."
• Source of truth: "Only use the information below. If the answer isn't there, say you don't know and give the shop's phone number."
• Tone and length: "Friendly, plain English, three sentences or fewer unless asked for detail."
• Hard rules: "Never promise a repair price that isn't listed. Never ask for card details."

Then test it with awkward questions: off-topic requests, rude messages, questions whose answers aren't in your content, and attempts to make it ignore its instructions ("forget your rules and…"). Adjust the prompt until the answers are ones you'd put your name to.

Keep costs predictable

Providers bill per token (roughly, pieces of words) for the input you send and the output the model writes. Three things drive the bill:

1. Conversation length. Each new message normally resends the whole thread so the model has context. A 40-message chat costs far more per reply than a 4-message one. Keep only the last several turns, or summarise older ones.
2. Prompt size. A long system prompt or a big block of pasted knowledge is sent with every message.
3. Output length. Set a maximum reply length in the API call and ask for concise answers in the prompt.

Set a monthly spending limit in the provider's dashboard before you launch, and log token usage per request so you can see which conversations are expensive. We don't quote prices here because they vary by model and change often; check your provider's own pricing page.

Build it step by step

Step 1: Describe the bot, not the code

A first prompt that names the audience, the scope, the data and the safety rules gets you most of the way:

Build a customer help chatbot for Oakline, a bike repair shop. A chat page with a message list and input, replies streamed as they're written. Call the Anthropic API from a server route using the secret ANTHROPIC_API_KEY — never expose it to the browser. Use a system prompt that only answers questions about our services, prices and hours from the text in a file called shop-info.md, and says "I'm not sure — call us on the number below" otherwise. Limit messages to 500 characters and 20 messages per visitor per hour. Clean, friendly design that works on phones.

Step 2: Add the key as a secret

Create the key in your provider's console, then store it in the project's environment variables or secrets, not in the chat and not in the code. If a key ever appears somewhere public, revoke it at the provider and create a new one. What environment variables and secrets are explains why this matters.

Step 3: Test the answers, not just the interface

Once the chat works, spend most of your time on answer quality. Keep a list of 20 or so real questions, including a few that should be refused, and run through them after every prompt change. Check:

• Does it stay within scope?
• Does it admit when it doesn't know, instead of inventing an answer?
• Does it hold up when someone tries to override its instructions?
• Is the key absent from anything the browser downloads?

Step 4: Add memory and accounts if you need them

Once single conversations work, ask for saved threads in a database and, if needed, sign-up and login so each user sees only their own chats. Add a per-user daily message allowance at the same time.

Step 5: Publish with the limits switched on

Make sure the published app has the same secrets as the preview, the spending cap is set at the provider, and errors are logged somewhere you'll see them. Then share it with a small group before putting it on your main site.

Safety and trust

A chatbot talks to the public in your name, so treat its failure modes as your problem:

• Wrong answers. Models can state false things confidently. Keep the bot on a narrow topic, ground it in your own content, and show a short note that answers may be wrong on anything important.
• Prompt injection. Users (or documents the bot reads) can contain instructions like "ignore previous rules". Don't give the bot powers it can't be trusted with: no refunds, deletions or emails sent on a user's say-so without a check in your own code.
• Sensitive topics. For medical, legal or financial questions, have it point people to a professional rather than advise.
• Personal data. Don't paste customer records into prompts unless you need to, and check what your provider's terms say about how API data is handled.

Our security checklist for AI-built apps covers the wider app.

Common mistakes

• Calling the provider from the browser. The key leaks. Always go through your server.
• No limits on a public bot. One script can drain a month's budget in an afternoon.
• Starting with RAG, tools and multiple models at once. Get one good conversation working first; add the rest when real questions show you need it.
• Testing only friendly questions. Your users will ask odd, hostile and off-topic things on day one.
• Letting the thread grow forever. Costs and response times climb with every message.

When a ready-made product is the better choice

Building your own makes sense when the chatbot is part of your product, needs your own data or workflow, or needs a specific look and behaviour. It is often the wrong call when:

• You only want a support widget on an existing site. Many helpdesk and live-chat products now include AI answer bots that read your help centre, with human handover, inbox and reporting already built.
• Only you or your team will use it. A subscription to a general assistant such as ChatGPT or Claude, with your documents uploaded, may be all you need.
• You need strict compliance guarantees (for example, regulated health or financial data). A vendor that already has the certifications may be safer than a custom build.

Building it with Mythex

Mythex is an AI app builder: you describe the chatbot in chat, and it writes the interface and the server-side call, runs it in a live preview and publishes it to a public URL. The AI inside your app uses your own provider key. You add it in project secrets, or through the secrets card Mythex shows in chat when it needs one, and provider usage is billed to your provider account, not to Mythex build credits. Mythex doesn't include tokens for your app's users, a built-in knowledge-base product, or ready-made rate limits: those are parts you ask for and test. The docs page on adding AI inside your app walks through it, and add AI with your own API keys has a starter prompt.

If the bot needs saved threads, Mythex attaches a Postgres database to the project when you ask for one. For more ways to use models inside an app, from summaries to classification, see how to add AI features to your app, or browse the app templates for starting points.