How to Build RAG Chatbots for Clients as a Freelancer

Building a RAG chatbot is the easy part. Getting a client, agreeing on what you will build, keeping their documents safe, and getting paid on time: that is where freelancers get stuck.

This post is a simple, step-by-step guide to doing client work with RAG chatbots, from the first call to the monthly check-in. It is part 4 of my RAG series:

• Part 1: How to Build a "Chat With Your PDFs" App
• Part 2: Why Your RAG Chatbot Gives Wrong Answers
• Part 3: How Much Does a RAG Chatbot Cost to Run?

You do not need to read them first, but I will point to them when they help.

Who Needs a RAG Chatbot (and What to Promise)

The best clients are small businesses that answer the same questions again and again. For example:

• Coaches and trainers (course details, schedules, rules)
• Real estate agents (listing details, documents, process)
• Clinics and training centers (timings, services, forms)
• Online shops (return policy, shipping, product details)
• Software teams (help center and documentation)

They all have two things in common: they already have documents with the answers, and someone on their team is tired of typing the same replies.

What you can promise:

• The chatbot answers questions using only the client's documents.
• It works day and night.
• It shows where the answer came from, so people can check it.
• When it does not know, it says so and shows how to contact the business.

What you should never promise:

• That it knows everything
• That it is always right
• That it replaces the client's staff

Promising less and delivering what you promised is how you get repeat work.

A tip on finding clients: start with one type of business. When you know one type well, your demo, your questions, and your pitch all get better. Show them a demo on their own document (see step 3 below). People believe what they can see working.

The Client Process, Step by Step

Step 1: The first call

The goal of this call is to understand the problem, not to sell. Ask the questions in the next section. At the end, say what you need next: a few real documents and a list of the questions customers ask most.

Step 2: Collect the documents

Ask for the original files, not photos or screenshots. Word, PDF with real text, or plain text files are best. Ask three things:

• Are these documents up to date?
• Is anything in them private or secret?
• Who in the business can answer my questions about them?

Open every file yourself. As we saw in part 2, messy or scanned PDFs are one of the main reasons for wrong answers.

Step 3: Make a small free demo

Take one short document from the client, 1 or 2 pages, and build a working chatbot on it. Show it to them with 5 real questions.

Keep the free part small. A demo on one document shows them it works. Building the whole project for free does not. Do not start the real build until the scope is agreed and the first payment is made.

Step 4: Agree the scope in writing

This is the most important step, and most beginners skip it. Write one page that says what you will build and what you will not. There is a template in the next sections.

Step 5: Build

Use the same steps from parts 1 and 2: extract the text, clean it, split it into chunks, embed it, store it, and answer from it. Keep each client's data separate (code below).

Step 6: Test with 20 real questions

Ask the client for 20 questions that their customers really ask. You can find them in their WhatsApp chats, emails, or social media messages. Run all 20 through the chatbot and mark each answer as:

• Right
• Partly right
• Wrong

Fix the problems, then run all 20 again. Do not launch until every answer is right, or the bot safely says "I could not find this". Show the client the results. It builds trust and it sets honest expectations.

Keep these 20 questions. You will use them again every month.

Step 7: Launch and hand over

Give the client the link, QR code, or website widget. Then spend 30 minutes with them:

• Show how people use it.
• Show how to send new or changed documents.
• Explain what it can and cannot do.

Give them a one-page guide they can keep.

Step 8: Support period

Say in the scope how long you will fix problems for free after launch (for example 2 weeks). After that, monthly support starts.

Questions to Ask Before You Start

1. What questions do your customers ask most? Can you give me 20 real examples?
2. Who will use the chatbot: customers, your staff, or both?
3. Which documents should it use? How many pages? In which languages?
4. Where should it live: a link, a QR code, your website, or WhatsApp?
5. How often do the documents change? Who will send me the new versions?
6. What should the chatbot never talk about? (For example prices, medical advice, or legal advice)
7. What should it say when it does not know the answer?
8. Is any document private or secret?
9. Who will pay for the AI usage: you or me? (More on this below.)

The One-Page Scope

Here is a simple template. Copy it, change it for each client, and send it before you start. (I am not a lawyer. For bigger projects, ask a lawyer to look at your template once.)

PROJECT: AI chatbot for [Client name]

WHAT IT DOES
- Answers questions using only the documents you give me.
- Shows which document the answer came from.
- Says "I could not find this" and shows your contact details
  when the answer is not in the documents.

WHAT IT DOES NOT DO
- It does not give legal, medical, or financial advice.
- It does not use information outside your documents.
- It does not take bookings, payments, or other actions
  (these can be added later as a paid extra).

DOCUMENTS
- Up to [number] documents / [number] pages, in [language].
- The timeline starts when I receive all the documents.

LIMITS
- Up to [number] questions per month.
- Above that, extra questions cost [amount] per [number].

AI COSTS
- Paid by: [client / me]. Billing account: [client's / mine].

OWNERSHIP
- You own your documents and your chatbot's content.
- I own the code. You get the right to use it for your business.
  (Change this line if you agree something different.)

UPDATES
- [Number] document updates per month are included.
- More updates: [amount] each.

SUPPORT
- Free fixes for [2 weeks] after launch.
- After that: monthly support at [amount] per month.

PAYMENT
- Setup fee: [amount]. [50%] before I start, the rest at launch.
- Monthly fee: [amount], paid on [date].

The most important lines are "What it does not do", the question limit, and "Paid by". These three stop most arguments before they start.

Keep Client Documents Safe

Clients trust you with their documents, and some are private. Follow these rules every time:

• Never use free AI tiers for client data. As I explained in part 3, a free tier can use your content to improve the provider's products. Use paid accounts.
• Tell the client which AI company processes their text. No surprises.
• Keep every client's data separate. A question from client A must never see client B's documents. See the code below.
• Answer only from the documents. Use the strict prompt from part 2.
• Add a short note for risky topics. If the client is a clinic, a lawyer, or gives money advice, add a line like "This is general information from our documents, not professional advice."
• Keep API keys out of your code. Use environment variables.
• Sign an NDA if the client asks. And only collect the documents you need.
• Delete on request. When a client leaves or asks, delete their documents, their vectors, and their saved questions. Tell them when it is done.
• Back up your data. And test that you can restore it.

Privacy rules are different in every country. If your client works with personal data, ask them which rules apply.

One App, Many Clients

You do not need a new app for every client. One app can serve many clients, if each client has their own config and their own data folder. Here is a simple example (the names are made up):

import json
import faiss

CLIENTS = {
    'client-a': {
        'name': 'Client A',
        'index_path': 'data/client-a/index.faiss',
        'chunks_path': 'data/client-a/chunks.json',
        'tone': 'friendly and short',
        'monthly_limit': 1000,
        'fallback': 'Please contact us at [e-mail]',
    },
    'client-b': {
        'name': 'Client B',
        'index_path': 'data/client-b/index.faiss',
        'chunks_path': 'data/client-b/chunks.json',
        'tone': 'formal',
        'monthly_limit': 500,
        'fallback': 'Please call our office.',
    },
}

def load_client(client_id):
    config = CLIENTS[client_id]
    index = faiss.read_index(config['index_path'])
    with open(config['chunks_path']) as f:
        chunks = json.load(f)
    return config, index, chunks

def build_prompt(config, context, question):
    name = config['name']
    tone = config['tone']
    fallback = config['fallback']
    return f'''You are the assistant for {name}.
Answer using ONLY the context below. Use a {tone} tone.
If the answer is not in the context, say: 'I could not find this. {fallback}'

Context:
{context}

Question: {question}
Answer:'''

def within_limit(client_id, questions_this_month):
    return questions_this_month < CLIENTS[client_id]['monthly_limit']

The important idea: every question comes in with a client_id, and the app loads only that client's index. It never searches across clients. If you use a hosted vector database, the same idea works with one namespace or one index per client.

Pricing in 5 Steps

1. Work out the running cost. Hosting + database + AI at the client's expected number of questions. In part 3, a small business with about 1,000 questions a month came to roughly $8 to $15 a month, using prices I checked on October 6, 2026. Check current prices before you quote.
2. Count your time. Time to collect and clean documents, build, test, train the client, and support them later.
3. Set a setup fee. This pays for the first build. Ask for part of it (for example half) before you start.
4. Set a monthly fee with a question limit. It must cover the running cost, your update and support time, and some room for busy months.
5. Set a price for extras. Extra questions above the limit, extra document updates, new features.

Do not charge only your costs. The running cost for a small client is small. Your fee pays for your work, your reliability, and your time to keep the chatbot good.

The question of who pays the AI bill matters too. One simple way is for the client to create their own AI account and give you the key. Then their usage is their own cost, and you carry no risk. The other way is to pay the bill yourself and include it in your monthly fee, with a question limit to protect you.

Common Problems and What to Do

Problem	What to do
Documents are messy or scanned	Ask for the original files. If you can't get them, use OCR, check the text yourself, and charge for the cleanup. (See part 2.)
The bot gives a wrong answer	First print the retrieved chunks. Often the answer is missing from the documents, or the text extraction is bad. Fix the cause, then re-run the 20 test questions. (See part 2.)
The client asks for more features ("Can it also book appointments?")	Open the scope page. If it is not in there, it is a paid extra. Say it kindly and give a price.
The client expects it to know everything	Show the 20-question test results. Explain that the bot only knows the documents. Make sure the "I could not find this" answer shows how to contact them.
Old answers after documents change	Ask the client to send every new version. Embed only the files that changed. (See the hash tip in part 3.)
The client is slow to send documents	The timeline starts when you get all the documents. Write this in the scope.
Someone spams the public chatbot	Add a daily limit for each visitor and a monthly budget alert. (See part 3.)
The client is late to pay	Take part of the setup fee before you start, and pause support if the monthly fee is not paid. Write this in the scope.

A Simple Monthly Routine

The monthly fee is only fair if you do real work. Here is a routine you can follow for every client:

1. Check usage. How many questions did people ask? Are they near the limit? What was the AI bill?
2. Read the questions. Look at the ones where the bot said "I could not find this". They show what information is missing from the documents.
3. Re-run your 20 test questions. Make sure nothing broke.
4. Update the documents if the client sent new files.
5. Check hosting and backups.
6. Send the client a short note. Number of questions, the top questions, and the topics that are missing. This note shows the client what they are paying for, and it often leads to more work.

Your Checklist

Before you start

• [ ] I asked the discovery questions.
• [ ] I have the original documents, and I opened every one.
• [ ] I have 20 real customer questions.
• [ ] The one-page scope is signed or accepted in writing.
• [ ] The first payment is received.

Before launch

• [ ] Each client has their own data and config.
• [ ] The prompt answers only from the documents and has an "I could not find this" line.
• [ ] Sources are shown with every answer.
• [ ] All 20 test questions are right, or safely say "I could not find this".
• [ ] A public bot has limits and budget alerts.
• [ ] API keys are in environment variables, not in code.

After launch

• [ ] I gave the client a 30-minute training and a one-page guide.
• [ ] The support period is in writing.
• [ ] I have a monthly routine in my calendar.

Wrap-Up

Good RAG client work is not only about code. It is about promising the right things, agreeing the scope in writing, testing with real questions, keeping data safe, and checking in every month. Do those well, and one small client can become a steady monthly income.

If you would like a working codebase to start from instead of building everything yourself, I made a RAG chatbot source-code kit: Source code: .

Are you building RAG chatbots for clients, or planning to? Tell me in the comments what is your biggest worry, and I will try to cover it in the next part.

Comments

[Mohith kumar]

Agree that the build is the easy part. Scoping is where freelance RAG projects go wrong: which documents, who maintains them, what counts as a correct answer. I'd collect those in a written brief before quoting. I built chatform.in for briefs like that; it asks one question at a time and follows up when the client says "all our docs".