A working chatbot prototype is built in two weeks today. A language model, a few prompts, an integration into the website, and you are done. This is precisely what regularly leads to the assumption that a custom build is the more cost-effective choice.
The decision is made at a different point. It is made when asking whether you want to operate this chatbot for three years. The build is the visible part. What comes after is not in any prototype.
This article describes what typically breaks after twelve months, when a custom build is the right decision, and which five questions anticipate the choice.
What a custom build delivers in the beginning
Do not underestimate the prototype. A team with a good developer can quickly get a bot that provides plausible answers, runs on the website, and convinces in the demo meeting. Configuration and prompt work are well-documented, models are accessible via APIs, and sample code is abundant.
This phase almost always succeeds. However, it creates a distorted picture of the effort because it represents the part that requires the least work.
What breaks after twelve months
Five issues keep coming up in failed custom builds. What they have in common is that they remain invisible in the prototype.
Context across multiple channels. As long as the bot only runs on the website, state management is simple. As soon as WhatsApp, app, and phone are added, you need a shared knowledge base, a shared session model, and routing that remains consistent across channels.
Reliability over long conversations. The common safeguard writes rules into the system prompt. These rules lose their effectiveness as the conversation length increases, and this is true for every current model. A study of eighteen current models shows that all lose accuracy with increasing input length. Those who secure compliance via prompts are building a boundary that shifts during operation. The mechanics behind this are described in our article on Context Rot.
Data maintenance as a permanent role. Product data changes, processes change, and wordings become outdated. Without a workflow for preparation, review, and versioning, the answer quality drops slowly and unnoticed. This work is part of operations and runs continuously.
Duty of disclosure. Whoever has provided information bears the burden of proof. A company is liable for the statements of its chatbot, as decided by the Higher Regional Court of Hamm in May 2026. Added to this are the transparency requirements of the EU AI Act. An audit trail, source citation per answer, and documented data flows are therefore not optional extras.
Architecture instead of model choice. A research team from UC Berkeley analyzed 1,642 execution logs from seven multi-agent frameworks. The error rates range between 41 and 86.7 percent depending on the benchmark. The distribution is remarkable: 44.2 percent of errors are due to system design, 32.3 percent to misalignment between components. The vast majority of problems arise at the point where custom builds invest the least.
The line item that is in no calculation
Custom build calculations usually list development days and model costs. The larger line item is the permanent staffing: someone who maintains the knowledge base, tracks rule violations, fine-tunes during model changes, and reacts to API changes.
This person is not a full-time position at the start and grows with usage. As soon as they leave the company, the knowledge about the bot goes with them. Therefore, calculate the custom build over three years, including personnel retention.
How the cost side of a purchased system is composed can be found in our article on what an AI chatbot costs.
When a custom build is the right decision
There are cases where building it yourself is sustainable. Four of them.
The use case is your product. If the assistant itself is what you make money with, it belongs in your own development.
You have an existing platform team. A team that already operates, monitors, and develops services can support an additional service with manageable extra effort.
The use case is narrow and stable. A self-contained internal use case with few sources and no legal consequences can easily be mapped yourself.
Regulations require full control over the stack. In a few industries, in-house production is a mandate, not a choice.
If none of these points apply, the calculation shifts. How to systematically compare providers after that is explained in the Selection Guide for Chatbot Providers.
The middle ground that many choose
In practice, the decision is rarely binary. A common division is to purchase the platform with knowledge management, guardrails, channels, and audit trails, while dialogues, process logic, and integration into your own systems are built in-house. This keeps the business ownership internal without you having to operate the infrastructure yourself long-term.
In this case, check whether the platform can be operated without developer involvement. Otherwise, you are just swapping one dependency for another.
Five questions before the decision
Who will maintain the knowledge base in eighteen months, by name?
What happens when this person leaves the company?
How do you prove in the event of a dispute what an answer was based on?
What does it cost to switch to another model if your provider changes the terms?
How many channels should there be in two years, and who will keep them consistent?
If you can answer four of these five questions without hesitation, you have the prerequisites for a custom build. If not, you are buying exactly these answers with a platform.
Frequently Asked Questions
Is ChatGPT or another language model not enough?
For open questions and text work, yes. For customer service information, company-specific, verified content, permission checks, and auditability are missing. A model alone knows nothing about your contracts, inventories, and processes.
How long does a custom build realistically take?
The prototype is built in weeks. Production operation with system integration, permission checks, multi-channel capability, and documentation is a project of a different scale, and it does not end with the go-live.
What about open-source frameworks?
They save licensing costs and shift the effort into integration and operation. The five issues mentioned above remain; they just become your task.
How do I avoid vendor lock-in?
Clarify before signing the contract in which format you will get back your knowledge base, dialogues, and conversation data, how long the contract term and notice period are, and whether your business units can work without developers.
Can we continue building on a purchased system ourselves later?
This is common practice via open interfaces. Check if the platform offers a documented REST-API and if you are allowed to connect your own processes.
Isn't a custom build more individual?
An assistant becomes individual through your data, your dialogues, and your processes. These components remain yours in both approaches.
Sources
Cemri, Pan, Yang et al., "Why Do Multi-Agent LLM Systems Fail?", UC Berkeley
Chroma Research, "Context Rot: How Increasing Input Tokens Impacts LLM Performance"
OLG Hamm, judgment of 12.05.2026, Case No. 4 UKl 3/25
