DEV Community: buildbyalex

A 12,400-item B2B parts catalog on Next.js with quote requests straight to the inbox

buildbyalex — Sun, 04 Oct 2026 12:07:35 +0000

Baltic Dockyard supplies certified parts for marine engines, pumps and offshore rigs. Offline the business worked. Online it barely existed: requests came through scattered channels, there was no email on the company domain, and procurement managers and ship engineers could not find the supplier in search.

We built the whole thing end to end on Next.js. A few notes on what a B2B parts catalog actually needs.

A catalog of 12,400+ items in two languages

The storefront is bilingual, Polish and English, with more than 12,400 items across six departments, plus delivery and company pages. Professional buyers do not browse like shoppers. They arrive with a part number or a very specific query, so the catalog has to be:

fast on any device, including a phone in an engine room;
indexable item by item, with structured data;
correctly linked between languages with hreflang, so Google shows the Polish page to a buyer in Gdańsk and the English one to a buyer in Rotterdam.

No cart, a quote request instead

Marine parts are rarely bought with a card. Buyers need a price for their quantity, delivery terms and sometimes a certificate. So instead of a checkout every item leads to a quote request, and the form sends everything straight to the company inbox, including files and specs the buyer attaches.

A simplified version of the route handler with Resend:

// app/api/quote/route.ts
import { Resend } from "resend";

const resend = new Resend(process.env.RESEND_API_KEY);

export async function POST(req: Request) {
  const form = await req.formData();
  const files = form.getAll("files") as File[];

  const attachments = await Promise.all(
    files.slice(0, 5).map(async (f) => ({
      filename: f.name,
      content: Buffer.from(await f.arrayBuffer()),
    }))
  );

  const { error } = await resend.emails.send({
    from: "Quote form <noreply@example.com>",
    to: "sales@example.com",
    replyTo: String(form.get("email")),
    subject: `Quote request: ${form.get("part")}`,
    text: [
      `Part: ${form.get("part")}`,
      `Quantity: ${form.get("qty")}`,
      `Company: ${form.get("company")}`,
      "",
      String(form.get("message") ?? ""),
    ].join("\n"),
    attachments,
  });

  return Response.json({ ok: !error }, { status: error ? 502 : 200 });
}

Setting replyTo to the buyer's address sounds trivial, but it means the sales team answers with one click from their normal inbox, without copying addresses around.

Domain email

The company also got corporate email on its own domain. For B2B this is not cosmetic: a quote from a free mailbox looks like a reseller, and some procurement departments may not take it seriously at all.

Content for professional queries

On top of the catalog there is technical and on-page SEO (structured data, hreflang, speed) and a Knowledge Base with expert articles. Engineers search for answers to technical questions long before they search for a supplier, and those articles are how the company appears at that stage.

What we took from it

Match the buying process. In B2B a good quote form beats a cart.
Every item is a landing page. With thousands of SKUs, structured data and hreflang do most of the SEO work.
Make replying effortless. Requests in the normal inbox with attachments and a correct reply-to get answered faster.

Full case: Baltic Dockyard case study. If you need a catalog or company site like this, see website development.

Building an AI workout coach in SwiftUI: one-tap logging during the set, GPT-4o analysis after

buildbyalex — Sun, 04 Oct 2026 08:57:41 +0000

Most people who track their training in a notes app lose the one thing that matters: set-by-set context. The note does not remember what you lifted last week, and generic gym trackers bury the screen in charts without ever telling you what to do next.

The brief for Body Forge was a coach in your pocket: clean tracking during the set, real analysis after it, and programmes that adapt as you progress. Here is how the native iOS app is put together.

During the set: show almost nothing

The workout screen is built for one hand and a sweaty thumb. It shows only:

last week's sets for this exercise;
a rest timer;
weight and reps;
one tap to log the set.

Everything else waits until the session is over. Between sets nobody wants to read a graph.

After the session: let the model read the whole workout

When the workout ends, the app sends a compact summary to GPT-4o: volume, intensity and progression compared with the last three weeks. The model writes a short, personal analysis with concrete changes for next time, for example: stalled on incline press three weeks in a row, deload to 80% next week.

The trick is what you send. Raw logs are noisy, so the app builds a small structured summary first. Simplified:

struct ExerciseSummary: Codable {
    let name: String
    let sets: [SetEntry]          // weight, reps, rest
    let topSetLast3Weeks: [Double]
    let volumeChange: Double      // vs. the previous session
}

struct WorkoutSummary: Codable {
    let date: Date
    let programme: String         // e.g. "Upper/Lower, week 4"
    let exercises: [ExerciseSummary]
    let avgHeartRate: Int?        // from HealthKit, if available
}

The model gets numbers it can reason about, not a wall of text, and the answer comes back in about 10 seconds.

The rest of the stack

SwiftUI on iOS 17 and later;
Core Data locally with CloudKit sync, so history survives a new phone;
HealthKit for heart rate during the session;
a programme library: Upper/Lower split, full-body for beginners, custom blocks;
more than 200 exercises with video form demos;
Russian and English localisation.

The landing page

An App Store link does not explain why one tracker is better than a hundred others, and it does not rank in search. The app got its own bilingual site, bodyforges.com, in the same dark style with one goal per screen: go to the App Store. The first screen paints in about 0.7 seconds.

What we took from it

Design the in-workout screen for the worst moment. Tired, one hand, ten seconds of attention.
Summarise before you prompt. A structured summary gives better analysis than raw logs, and it is cheaper.
Make the advice concrete. "Deload to 80% next week" is useful, "keep pushing" is not.

Body Forge is live in the App Store. Full case: Body Forge case study. We build apps like this for small teams and founders, more on mobile app development.

A RAG consultant for an immigration law firm: what it answers and what it hands to the lawyer

buildbyalex — Sun, 04 Oct 2026 08:56:37 +0000

An immigration lawyer in Warsaw was spending hours a day on the same questions. Which documents do I need for a karta pobytu? How long does it take? Her site was a brochure: it brought no leads from Google, and every first message was answered by hand.

We rebuilt the site and put a consultant inside it that answers from the firm's own material. Here is the shape of it.

The site first

The assistant only helps if people reach the site, so the groundwork came before any AI:

Next.js 15 with proper localized routing in Russian, Polish and Ukrainian, because most clients do not read Polish comfortably;
LegalService structured data;
separate pages for commercial queries such as "karta pobytu Warszawa" or "pobyt stały Polska", instead of one page that tries to cover everything.

The consultant: retrieval before generation

The assistant runs on GPT-4o with retrieval. The knowledge base is built from more than 200 real cases the firm has handled and from official documents published by the offices that issue the decisions. Chunks are stored as embeddings in Postgres with pgvector.

The flow for every question is short:

embed the question;
pull the closest chunks from pgvector;
answer only from those chunks, in the language the client wrote in;
if the chunks do not cover the question, say so and offer a consultation.

A simplified version of the retrieval query:

select content, source
from kb_chunks
where locale = $2
order by embedding <=> $1
limit 6;

And the core of the instruction the model gets:

Answer using only the context below. If the context does not contain the answer,
say that this needs an individual consultation and ask for the client's contact.
Never guess deadlines, fees or document lists.

The last line matters most. In immigration law a confident wrong answer about a deadline costs a client far more than "please ask the lawyer".

Handing over the lead

The assistant does not try to replace the consultation. Once it has answered the standard part, it asks for contact details, country and the gist of the case, and sends a ready request to the lawyer's Telegram. She opens one message and already knows whether this is a residence card refusal, citizenship or family reunification.

Results

The site ranks in Google's top 10 for more than 15 commercial queries in Poland.
The assistant handles about 80% of first contacts on its own.
A client gets an answer in seconds instead of waiting hours.
The site shows the firm's real rating: 4.9 stars from 312 clients.

An unexpected bonus: ChatGPT now names the site when people ask it about immigration help in Warsaw. Clear service pages and structured data seem to help there as well as in Google.

What we would tell anyone building this

The knowledge base is the product. Real cases and official documents beat any clever prompt.
Teach the bot to say "I don't know". For legal, medical or financial topics, a refusal with a handover is a feature.
Send the lawyer a summary, not a transcript. Contact, country, topic and the question in two lines.

Full case: LegalWin case study. More on how we build assistants like this: AI chatbot development and our notes on chatbots that answer from your own data.

Lead forms that reach the phone in under 2 seconds: Next.js + Telegram for a small business

buildbyalex — Sat, 03 Oct 2026 09:12:23 +0000

A drone operator in Warsaw had a steady flow of enquiries, but they went cold. By the time he replied, the client had already written to someone else. His old site took around 4 seconds to load and did not rank for any of his seven services.

We rebuilt it on Next.js with two goals: get found for each service separately, and get every request onto his phone before the client opens another tab.

One page per service

He shoots weddings, real estate, infrastructure inspections, advertising, events, sports and documentation. Each of those got its own page with:

its own schema markup;
real photos from that type of shoot;
a starting price;
an FAQ written from the questions clients actually ask.

People search for "drone wedding video Warsaw" or "roof inspection drone", not for "drone services". A single generic page cannot rank for seven different intents, seven focused pages can. Starting prices also filter out people who would never book, so the requests that do come in are warmer.

The form writes straight to Telegram

No CRM, no shared inbox. The contact form posts to a Next.js route handler, which checks a rate limit in Upstash Redis and sends the request to the operator's Telegram through the Bot API. A simplified version:

// app/api/lead/route.ts
import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(3, "10 m"),
});

export async function POST(req: Request) {
  const ip = req.headers.get("x-forwarded-for")?.split(",")[0] ?? "unknown";
  const { success } = await ratelimit.limit(`lead:${ip}`);
  if (!success) return Response.json({ ok: false }, { status: 429 });

  const { name, contact, service, message } = await req.json();
  if (!contact || String(message ?? "").length > 2000) {
    return Response.json({ ok: false }, { status: 400 });
  }

  const text = [
    `New request: ${service}`,
    `Name: ${name}`,
    `Contact: ${contact}`,
    "",
    message,
  ].join("\n");

  const res = await fetch(
    `https://api.telegram.org/bot${process.env.TG_TOKEN}/sendMessage`,
    {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ chat_id: process.env.TG_CHAT_ID, text }),
    }
  );

  return Response.json({ ok: res.ok }, { status: res.ok ? 200 : 502 });
}

Two small details that save trouble. Send plain text without parse_mode, otherwise one underscore in a client's email breaks Markdown parsing and the message never arrives. And return an error to the form when Telegram fails, so the visitor sees a fallback contact instead of a fake "thank you".

Indexing on every deploy

New service pages should not wait a week for a crawler. On each deploy the build sends changed URLs to IndexNow, which Bing and other participating search engines pick up:

await fetch("https://api.indexnow.org/indexnow", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    host: "example.com",
    key: process.env.INDEXNOW_KEY,
    urlList: changedUrls,
  }),
});

Results

LCP under 1 second on all seven service pages.
A request reaches the operator's Telegram in under 2 seconds.
New pages get indexed in hours rather than days.
Visitor-to-lead conversion went from 0.8% on the old site to 4.2%.

What we took from it

For a small service business the fastest reply usually wins the job, and a form that lands in a messenger the owner already checks all day beats any CRM he will not open. Separate pages with real prices bring both search traffic and better-qualified requests.

The full case is on our site: VisionAir case study. If you need a site like this for your own business, see website development.

An LLM agent that qualifies B2B leads from AmoCRM: notes from a production build

buildbyalex — Sat, 03 Oct 2026 09:10:58 +0000

A B2B client came to us with 50 to 80 inbound leads a day and one first-touch sales manager. About six hours of that person's day went to the same questions: what are your prices, can you send the deck, do you work with our volume. Filtering was uneven, and some leads never got a reply at all.

We replaced that first touch with an LLM agent. Here is how it is put together and what we would keep if we built it again tomorrow.

What the agent does

Every morning it pulls new leads from AmoCRM through API v4. For each lead it:

classifies the request type, for example a price question or a request for materials;
opens a conversation in the channel the lead came from: Telegram, or WhatsApp through Wappi;
qualifies the lead on six criteria, among them volume, budget, timing and fit with the ideal customer profile;
moves the deal to the right pipeline stage and tags it.

An admin panel shows every dialog, and a manager can step into any conversation at any moment. That part matters more than it sounds. The sales team trusted the bot because they knew they could take the wheel whenever they wanted.

The stack is boring on purpose: TypeScript, Node.js with Express, Gemini 2.0 Flash as the model, Firestore for conversation state.

Function calling instead of free text

The model never writes to the CRM in prose. It can only call a short list of functions, and the backend validates every argument before anything touches AmoCRM. A simplified version of the qualification call looks like this:

const qualifyLead = {
  name: "qualify_lead",
  description: "Save qualification answers once the lead has given them",
  parameters: {
    type: "object",
    properties: {
      leadId: { type: "number" },
      monthlyVolume: { type: "string", enum: ["small", "medium", "large", "unknown"] },
      budgetConfirmed: { type: "boolean" },
      timing: { type: "string", enum: ["now", "this_quarter", "later", "unknown"] },
      icpFit: { type: "boolean" },
      notes: { type: "string" }
    },
    required: ["leadId", "monthlyVolume", "budgetConfirmed", "timing", "icpFit"]
  }
};

Enums do a lot of the work here. When the model has to pick unknown instead of making up a number, the CRM stays clean, and the sales team can filter on those fields without reading transcripts.

The rest of the toolbox follows the same idea: move a deal between stages, add a tag, send the deck or price list, hand the conversation to a human. Anything outside that list the agent simply cannot do. We wrote a longer piece on where to put approval gates when an agent has CRM or ERP access.

What changed after launch

Qualifying a lead takes about 8 minutes instead of 40.
Every inbound lead gets an answer, including the ones that arrive at night or on weekends.
The share of leads that reach a sales conversation went up 31%. That came from consistency alone: the same questions, asked every time, with nothing forgotten.

The manager who used to do first touch now works only with leads that are already qualified.

If you are building something similar

Start from the CRM fields, not the prompt. Decide what a qualified lead looks like as data, then make the model fill exactly those fields.
Keep the tool list short. Every extra function is one more way for the agent to do damage.
Give people a visible override. The admin panel was one of the cheapest parts of the project, and it is the reason the team accepted the bot.
Measure business numbers. Time to first reply and the share of leads that reach a sales call tell you more than any accuracy score.

The full case with screenshots is here: CRM Bot case study. We build agents like this for small and mid-size companies in Poland and the EU, more on the AI agents page.

AI agent permissions in CRM and ERP: where to put the approval gate

buildbyalex — Fri, 02 Oct 2026 14:30:58 +0000

Originally published on buildbyalex.com.

The hardest question in an AI agent project is not "which model" or "how much". It is what this agent may do in our CRM without asking anyone. While the agent only reads and answers, the risk is small. The day it gets write access, everything changes at once: the price of the build, the scope of testing, and the list of things that can go wrong quietly.

Below is what I put into projects: a permission matrix, rules for the approval gate, the audit trail, and a rollback plan. No governance theory, just fields and numbers.

The moment the agent stops reading and starts writing

Published Polish price bands show this threshold better than any explanation. In vendor price lists, an agent answering from a knowledge base and an agent writing into a system are two different products.

Agent scope	Bands published by Polish vendors	Running cost
Simple assistant on an off-the-shelf platform	€700-3,500 (3,000-15,000 zł)	€120-580/mo
Answers from a knowledge base, only reads your systems	€4,600-14,000 (20,000-60,000 zł)	€470-1,900/mo
Reads and writes data in CRM, ERP or a logistics system	€18,500-58,000 (80,000-250,000 zł)	€1,900-9,300/mo

The jump is not the model. Write access forces someone to design permissions, handle failures, plan how a change gets reverted and collect logs that survive a conversation with an auditor.

If your case is "I want customers to get answers from our documentation", stay in the top rows, which is chatbot with a knowledge base territory. Write access earns its keep only when someone retypes the same data by hand dozens of times a week.

The permission matrix: one table the owner signs

Every AI agent build that touches a live system starts with this document. One page, five columns, signed off before the first line of code.

Action in CRM or ERP	Risk	Agent permission	Approval gate	What goes to the log
Read a customer record and its history	low	read	no	record id, query, timestamp
Add a note to a case	low	write	no	note text, author "agent"
Create a lead from an email or form	low	write	no	source, fields filled
Move a deal to another pipeline stage	medium	write	yes, above €4,600 (20,000 zł) deal value	old stage, new stage, reason
Email a customer from a company address	medium	write and send	yes, on first contact	full body, recipient, attachments
Draft a quote or proposal	high	draft only	always	version, prices, discount, margin
Change price, discount or payment terms	high	no write, proposal only	always, manual confirmation	proposed value, reasoning
Issue an invoice and file it with the tax system	high	no write	always, a human clicks	full document payload
Change stock levels or reserve goods	high	write within a quantity cap	above the cap	SKU, delta, warehouse
Delete a record, merge counterparties	critical	forbidden	not applicable	the attempt and its rejection
Export a customer list or personal data	critical	forbidden	not applicable	the attempt and its rejection

Three rules keep this table honest:

Default zero. No permission exists until a row is added. Never the other way round.
One row is one action, not a module. "Access to the sales module" means nothing. "Move a deal to another stage" means something.
The critical tier stays empty. Deletion, merging and personal-data export are out of scope. A request for an exception usually means the process needs fixing instead.

A service account, not an employee login

The most common pilot shortcut: the agent gets a salesperson's login because it is faster. Three problems at once. The agent inherits every permission that person has, including forgotten ones. Record history shows the employee's name, so two months later nobody can tell their edits from the model's. And when that person leaves and the account is disabled, the agent stops mid-day.

The correct version is a separate service account with its own display name, API key, role set and rate limit. In HubSpot, Pipedrive, Zoho or a Comarch-class ERP that is an hour of work. Every record then shows the agent as the author, and revoking access touches nobody on the team.

The approval gate: what reaches a human, and how fast

An approval gate is not an "are you sure" dialog. It is a process step with a named recipient and a response time. Without those two it turns into a queue nobody reads.

Here is how I build it. The agent prepares the full action, saves it as a draft and sends one message to Slack or email: what it wants to do, on which record, on what basis, plus two buttons. If nobody answers in the agreed window, the action expires and the case moves to the manual list. It never fires on a default yes.

Windows that work in a small company: quotes within 4 working hours, first email to a new customer within 1 hour, above-threshold stage changes by end of day. For an agent that books appointments the line sits elsewhere: a free slot in normal hours it takes on its own, moving someone else's booking or an out-of-hours slot goes to a human.

How many cases really go to review

This question decides the budget, not the safety story. Builders running agents in production report that 5-15% of cases need a human, and that this is a permanent operating cost, not a defect to be engineered away. On top of that sits 100% of high-risk actions, which pass the gate by definition.

The arithmetic for a distribution company handling 400 cases a month:

exception review: 400 × 10% = 40 cases at 3 minutes, so 2 hours a month
quote approvals: 60 quotes × 4 minutes, so 4 hours a month
first-contact emails: 80 × 1 minute, roughly 1.5 hours

Just under 8 hours a month for one person, against the dozens of hours of manual data entry it takes off the team. Run this before the build: if it comes out at 40 hours of review, a rule-based automation is the better product.

Reviewing everything equally fails too. Somebody clicking "approve" for the fiftieth time stops reading within a week. The gate belongs where the matrix says "high"; the rest runs on its own and lands in the log.

Narrowing the blast radius: filters, caps and an allow-list of fields

"Write access to the CRM" is far too broad. I narrow it along four axes, set in configuration rather than in the prompt.

By record. The agent sees only cases in its own queue, not the whole database. Key accounts stay out of reach.
By field. An allow-list of writable fields, everything else read-only. Tax ID, owner details, contract terms and accounting fields never make the list.
By amount and quantity. Above €4,600 (20,000 zł) of deal value or a fixed unit cap, the agent can only propose.
By status. Closed, invoiced and disputed cases are locked entirely.

Those limits belong in the API and the permission model, not in the system prompt: a prompt can be bypassed with one carefully written customer email. OWASP's 2026 agent security work puts prompt injection at the centre of agentic risk and reports attacks up 340% year on year, with documented findings against Slack AI, Microsoft 365 Copilot and GitHub MCP. What the agent has no right to do in the API must stay impossible regardless of what it reads.

The audit trail: what has to survive every agent action

Agents rarely fail loudly. The typical failure is the agent calling the right tool with plausible but wrong parameters, and nobody noticing for a week. OWASP puts mean monitoring coverage across production agent systems at 52%, so close to half of deployed agents are not observed.

The minimum log record for reconstructing an event:

Field	Example content	Why
Timestamp and session id	2026-09-02 11:42, session 8f31	ties the action to a conversation
Who initiated it	customer, employee, schedule	accountability
Tool called and parameters	crm.update_deal, id 4127, stage=won	what actually hit the system
Prompt and model version	v14, gpt-5.1	reproducibility after a model upgrade
State before and after	stage: was negotiation, now won	rollback
Gate outcome	approved by Mark K., 11:48	proof of human oversight

A legal note, with the disclaimer: I am a developer, not a lawyer. A company running an AI system under its own name is a deployer under the EU AI Act, so the obligations sit with it, not only the contractor. Poland now has a national supervisor too: the AI Development and Safety Commission gains powers to inspect, run proceedings and impose fines from 28 October 2026. The agent's action log is the only thing you can put on the table there.

The rollback plan: cutting the agent off in a minute

The part that usually falls out of scope and hurts most when missing. Three levels, tested before launch, not after an incident:

Pause. One switch stops writes, reads keep running. Available to the owner, not only the contractor.
Cut-off. Revoke the service account's API key: seconds in the CRM panel, immediate effect.
Revert. A query over the log for the agent's actions in the last N hours, with the pre-change state, restorable in batches. Without it you read record history one row at a time.

Gartner expects over 40% of agentic AI projects to be cancelled by the end of 2027, and reports that 89% of agent pilots never reach production. Many failures look exactly like this: the pilot worked, then it did something stupid, nobody could say quickly what and how many times, so the project was shut down.

Where to start

The sequence that works: two weeks read-only, then low-risk writes, then one medium-risk action per week. High risk stays behind the gate permanently.

If you do not know which processes are even suitable for agent write access, start with an AI audit at 4,900 zł (about €1,140): you get the permission matrix and a build quote, sometimes the answer that a plain automation is enough. A sales agent with CRM integration starts at €2,500 with me, a multi-tool agent at €4,500. What that looks like from the business side I covered in deployments in Gdańsk.

Got a specific CRM or ERP process and want to know where the gate belongs? Write to me and we will go through the matrix for it.

FAQ

What permissions should an AI agent have in a CRM to start with?
Read access plus low-risk writes only: a note on a case, a lead from an email, updated contact details. Moving deals, emailing customers and anything touching price come later, behind an approval gate. Deleting records, merging counterparties and exporting personal data stay switched off permanently.

Which agent actions must always go through human approval?
Anything that changes money or creates an obligation to a customer: quotes, changes to price, discount or payment terms, issuing an invoice and filing it with the tax system, stock changes above a cap. Add the first email to a new customer and any deal change above a value threshold, say €4,600 (20,000 zł). The rest can run automatically as long as it lands in the log.

How many cases does an agent send to human review?
Builders running agents in production report 5-15% of cases as a standing operating cost, regardless of model quality. On top of that, 100% of high-risk actions pass the gate by definition. At 400 cases a month that is 6-8 hours of one person's time. If your calculation lands in the dozens of hours, a rule-based automation is the better answer.

What has to be logged on every agent action?
Six items: timestamp and session id, who initiated the action, the tool called with its parameters, the prompt and model version, the record state before and after, and the gate outcome with the name of the person who approved it. That set is enough to reconstruct an event and revert changes in batches. OWASP puts mean monitoring coverage across production agent systems at 52%, so the default state of the market is a log that is not good enough for this.

How much does an AI agent with CRM or ERP write access cost?
Polish vendors publish €4,600-14,000 (20,000-60,000 zł) for an agent answering from a knowledge base, and €18,500-58,000 (80,000-250,000 zł) setup plus €1,900-9,300 a month for one that reads and writes data in CRM, ERP or logistics. The jump comes from permission design, failure handling and logging, not from the model. With me a sales agent with CRM integration starts at €2,500 and a multi-tool agent at €4,500.

Is prompt injection a real threat to an agent with systems access?
Yes, and that is why limits belong in API permissions rather than in the model's instructions. OWASP's 2026 report puts prompt injection at the centre of agentic risk and reports attacks up 340% year on year, with documented findings against Slack AI, Microsoft 365 Copilot and GitHub MCP. One well-crafted customer email can make an agent attempt something outside its script. If the action is not in the service account's roles, the attempt ends in a rejection and a log entry.

How fast can an agent be cut off from a system?
On three levels. Pausing writes is a single switch that leaves the agent read-only. Revoking the service account's API key takes seconds in the CRM panel and applies immediately. Reverting is a query over the log for the agent's recent actions, with the pre-change state. Test all three before launch, not after an incident.

AI chatbot with a knowledge base for your site: answers from your own data, no made-up replies

buildbyalex — Thu, 01 Oct 2026 17:28:01 +0000

Originally published on buildbyalex.com.

The main worry about putting an AI bot on your site is simple: "what if it starts making things up and tells a client nonsense in the company's name." That worry is fair - a plain language model really can confidently invent something that doesn't exist. But a chatbot with a knowledge base works differently: it answers from your documents, not off the top of its head, and it says "I don't know" when there's no answer there. I build these bots, and I'll explain how it works, how it differs from a regular bot and what it costs.

Why a regular bot makes things up and this one doesn't

The difference is in where the answer comes from. A regular chatbot running on a bare language model generates its reply from everything it "knows" in general - and it can confidently invent a fact, a price or a condition that you don't actually have. For a business that's dangerous: the bot promised a client a discount, in your name, that doesn't exist.

A chatbot with a knowledge base works on a "find first, then answer" principle. When a question comes in, the system first searches your materials - on the site, in documents, price lists, manuals - for the relevant passage, and only then builds an answer strictly from what it found. If there's nothing in the base, the bot honestly says it doesn't know and offers to connect you with a person instead of inventing something.

This approach is called RAG - generation grounded in your data. For a business the point is one thing: the bot answers from your facts and doesn't fantasise. That's the difference between "putting AI on the site feels risky" and "we can do it with peace of mind."

What a knowledge base is and what it's built from

A knowledge base is everything the bot needs to know about your business, organised so it can find things fast. It's built from what you already have:

Site content - services, prices, terms, descriptions.
Documents - price lists, manuals, policies, contracts, regulations.
Frequent questions - what clients ask most often, with ready answers.
Past enquiries - real support conversations, if you have them.

The fuller and more accurate the materials, the better the bot answers. A key plus: the base is easy to update. Prices or terms change - you update the document, and the bot answers the new way right away, with no retraining or rewriting. That makes it a living tool, not a one-off setup.

What this bot does on your site

The concrete value it's put there for.

Answers client questions instantly and around the clock - from your data, at any time.
Takes load off support - it handles routine questions about prices, terms, availability and delivery on its own.
Helps people choose - it suggests the right service or product based on what the person needs.
Collects leads - if a client is ready, the bot takes their contact and passes it to CRM or a manager.
Hands off to a person when needed - a complex or unusual question goes to a live employee rather than getting lost.
Works beyond the site - the same knowledge base can be connected to a bot in Telegram, WhatsApp, or to support.

The effect: the client gets an answer right away instead of waiting, and some people make it all the way to a lead inside the conversation, without leaving to think it over.

Where it's especially useful

A bot with a knowledge base pays off where clients ask a lot of similar questions and where accuracy matters.

That's online stores with a wide range and questions about products and delivery, service companies with terms and tariffs, clinics and services with questions about procedures and prices, B2B with documentation and regulations, and any business where support drowns in repeating questions. It's especially useful where answers have to be accurate - prices, terms, rules - and where a mistake or a made-up reply is unacceptable. That's exactly why relying on a knowledge base, not on the model's imagination, is critical here.

How it's added to your site

Technically it's a few steps. First we gather your materials and tidy them into a knowledge base. Then we set up search across it and the answer logic - so the bot finds what's relevant and answers strictly from it. Then we connect the widget to the site and, if needed, to messengers, tune the tone to your brand and set the rules for handing off to a person. And we link it to CRM if the bot is meant to collect leads.

I set this up so the bot fits into your site and your processes rather than living off to the side. And I always set the boundaries: where the bot answers on its own, and where it honestly says "let me check with a specialist" and passes the question to a person. More on the approach is in the AI agent implementation service.

What it costs

The price depends on the size of the knowledge base and the complexity of the scenarios.

Basic bot with a knowledge base - 1,000-3,000 €. Building the base from the site and documents, answering questions, a site widget, handoff to a person.
Extended - 3,000-7,000 €. A larger base, several channels, lead collection into CRM, product or service recommendations, finer logic.
Complex implementation - from 7,000 €. A wide range or heavy documentation, strict accuracy and data requirements.

Plus a moderate monthly fee for the model's work based on the volume of enquiries, which is clear in advance. The payback is measured through saved support time and leads collected in conversation. For a business with a stream of similar questions, the bot usually pays for itself by taking load off people and by clients getting an answer right away instead of leaving.

FAQ

Will the chatbot make up answers?
No, not if it's a bot with a knowledge base. It answers not from the model's general knowledge but only from your materials: first it finds the passage relevant to the question in your base, then it builds an answer from it. If there's no answer in the base, the bot honestly says it doesn't know and offers to connect you with a person rather than inventing something. That's the key difference from a regular bot.

How is a bot with a knowledge base different from a regular chatbot?
A regular bot on a bare model generates its reply from what it knows in general and can confidently invent facts, prices or terms that don't exist. A bot with a knowledge base works on a "find it in your data first, then answer" principle and replies strictly from your materials. For a business that's the difference between the risk of a bot over-promising and peace of mind.

Where does the bot get its information?
From a knowledge base built from your materials: site content, price lists, documents, manuals, frequent questions and real support conversations, if you have them. The base is easy to update - prices or terms change, you update the document, and the bot answers the new way right away, with no retraining. The fuller the materials, the more accurate the answers.

How much does a chatbot with a knowledge base cost?
A basic bot with the base built from your site and documents, answers and a widget - 1,000-3,000 €. An extended one with a large base, several channels and lead collection into CRM - 3,000-7,000 €. A complex implementation - from 7,000 €. Plus a moderate monthly fee for the model's work based on the volume of enquiries. For a business with a stream of similar questions, the bot usually pays for itself by taking load off support.

Can this bot be put somewhere other than the site?
Yes. The same knowledge base can be connected to a bot on the site, in Telegram, WhatsApp and in support - the bot will answer just as accurately across all channels and collect leads in one place, for example in CRM. That's handy when clients write to you in different places: one knowledge base, several entry points.