Today, a working chatbot prototype can be built in two weeks. A language model, a few prompts, an integration into the website—done. That is precisely what regularly leads to the assumption that building in-house is the more cost-effective decision.
The real decision is made elsewhere. It comes down to whether you want to operate this chatbot for three years. Building it is the visible part. What comes next is never reflected in any prototype.
This article describes what typically breaks after twelve months, when building in-house is the right choice, and which five questions anticipate the decision.
What an in-house build delivers at the start
Do not underestimate the prototype. A team with a good developer can quickly produce a bot that gives plausible answers, runs on the website, and convinces stakeholders during a demo appointment. Configuration and prompt engineering are well documented, the models are accessible via APIs, and sample code is abundant.
This phase almost always succeeds. However, it creates a distorted picture of the required effort because it reflects the part that involves the least amount of work.
What breaks after twelve months
Five issues recur consistently in failed in-house 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, a mobile app, and telephony are added, you need a shared knowledge base, a unified session model, and routing that remains consistent across all channels.
Reliability over long conversations. The widespread safeguard is writing rules into the system prompt. These rules lose their effectiveness as the conversation lengthens—and this applies to every current model. A study of eighteen contemporary models shows that all of them lose accuracy as input length increases. Relying on prompts for compliance establishes a boundary that shifts during operation. The mechanics behind this are described in our article on Context Rot.
Data maintenance as an ongoing role. Product data changes, processes change, wording becomes outdated. Without a defined workflow for preparation, validation, and version control, response quality declines slowly and unnoticed. This work is an integral part of ongoing operations.
Evidentiary obligations. Whoever provides information bears the burden of proof. A company is liable for the statements made by its chatbot, as ruled by the Higher Regional Court (OLG) Hamm in May 2026. In addition, there are the transparency obligations under the EU AI Act. Consequently, audit trails, source citations for every answer, and documented data flows are not optional.
Architecture over model selection. A research team from UC Berkeley analyzed 1,642 execution traces across seven multi-agent frameworks. Depending on the benchmark, failure rates ranged between 41 and 86.7 percent. The distribution is striking: 44.2 percent of failures stem from system design, and 32.3 percent from misalignment between components. The vast majority of problems arise precisely where in-house projects invest the least.
The line item that appears in no calculation
In-house build estimates usually list development days and model costs. The larger cost item is the permanent staffing: someone who maintains the knowledge base, tracks rule violations, fine-tunes during model updates, and reacts to interface changes.
This role is not a full-time position at the start and expands with usage. As soon as that person leaves the company, the knowledge about the bot leaves with them. Therefore, calculate an in-house build over three years, including personnel retention.
To see how the cost side of a purchased system is structured, read our article on what an AI chatbot costs. The article Chatbot Costs: Why "Per Agent" Is a Mistake shows which pricing model aligns with scaling automation.
When building in-house is the right decision
There are scenarios where building it yourself is sustainable. Here are four of them.
The use case is your product. If the assistant itself is what generates your revenue, it belongs in proprietary in-house development.
You have an existing platform team. A team that already operates, monitors, and further develops services can support an additional service with manageable overhead.
The use case is narrow and stable. A self-contained internal use case with few sources and no legal implications can readily be built in-house.
Regulation mandates complete control over the stack. In a few industries, in-house development is a compliance requirement, not a choice.
If none of these points apply, the calculation shifts. You can learn how to systematically compare providers 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 buy the platform covering knowledge management, guardrails, channels, and auditability, while developing dialogues, process logic, and integration into internal systems in-house. This keeps domain authority internal without requiring you to permanently operate the underlying infrastructure yourself.
In this case, verify whether the platform can be operated without developer involvement. Otherwise, you simply swap one dependency for another.
Five questions to ask before deciding
Who specifically, by name, will maintain the knowledge base in eighteen months?
What happens when this person leaves the company?
In the event of a dispute, how do you prove what an answer was based on?
What does it cost to switch to another model if your provider changes terms?
How many channels will be active 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 an in-house build. If not, you are buying exactly these answers along with a vendor platform. The article No-Code Chatbot Platform: 10 Criteria lists ten evaluation criteria for maintenance without developers.
Frequently asked questions
Isn't ChatGPT or another language model enough?
For open-ended questions and drafting text, yes. For customer service inquiries, it lacks company-specific, verified content, permission checks, and auditability. A model on its own knows nothing about your contracts, inventory, or processes.
How long does an in-house build realistically take?
A prototype takes weeks. Production-ready operation with system integration, access control, multi-channel support, and documentation is a project of an entirely different scale—and it does not end with go-live.
What about open-source frameworks?
They save on licensing costs and shift the effort to integration and operations. The five challenges mentioned above still remain; they simply become your responsibility.
How do I avoid vendor lock-in?
Clarify before signing a contract in what format you can export your knowledge base, dialogues, and conversation data, what the contract term and notice periods are, and whether your business units can work without developers.
Can we expand on a purchased system ourselves later?
This is standard practice via open interfaces. Check whether the platform provides a documented REST API and allows you to integrate your own processes.
Isn't an in-house build more tailored?
An assistant becomes tailored through your data, your dialogues, and your processes. These components remain under your control either way.
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 May 2026, case ref. 4 UKl 3/25
About the Author
Johannes Tappmeier
Chief Executive Officer @Mercury.ai
Johannes Tappmeier is the CEO of Mercury.ai. He brings over 23 years of experience in the digital industry, previously holding leadership roles at the digital agency comspace. His focus is on translating complex challenges into organizational change through technology and agile practices.
