Build or buy an AI chatbot? The make-or-buy check for customer service in 2026

TL;DR — the essentials in 30 seconds

• With Claude, n8n or similar tools, you can build an AI chatbot prototype in an afternoon. The real costs only come afterwards, in maintenance.
• Self-built automations end up 30 to 50% more expensive than originally planned on average, because every new process variant adds more branching logic.
• Token costs fluctuate heavily and are rarely budgeted transparently. According to Gartner, AI coding costs per developer will exceed the average developer salary by 2028.
• A self-built chatbot isn't a learning system: without your own fine-tuning, it doesn't automatically get better with more customer requests.
• Both make and buy create a certain lock-in effect. The difference lies in how professionally it's managed and how many people are responsible for it.

🎙️ This article is based on episode #19 of our German-language podcast Service Sells: “Make or Buy”. In it, Maxi and Jakob discuss where in-house development in customer service hits its limits, from underestimated maintenance and token costs to legal pitfalls.

Definition:
‍The make-or-buy decision in AI customer service describes the choice between an automation solution developed in-house and a purchased SaaS platform. It concerns not just the initial development but above all ongoing maintenance, token costs, model quality, data protection and the question of who in the company is responsible for operations in the long term.

“We'll just build the bot ourselves” is one of the most popular sentences in customer service meetings right now. A developer sits down with Claude or n8n, and by the end of the afternoon there's a working prototype. But the real question isn't whether it can be built – it's whether the process can still be run and maintained sensibly in twelve months. That's what decides whether make or buy is the more economical choice for your company.

Why does building in-house with Claude, n8n and co. look so attractive right now?

Software development that used to easily cost €100,000 can now be prototyped in hours with vibe-coding tools. That's why many LinkedIn consultants currently recommend building it yourself: the barrier to entry has never been lower. What's missing from this discussion is the difference between a working demo and a productively operated AI agent that processes real customer data month after month without someone looking after it full time. A complaints process can be turned into a bot in a day. It only gets difficult when new exceptions come up during operation.

Reality check 1: who will maintain the self-built AI agent in twelve months?

In a self-built system, every new process variant adds more branching logic – a new if-statement in the decision tree behind the bot. After a few months, often only a single person in the company knows the complete flow. That's siloed knowledge in its purest form: the problem isn't building it, but concentrating the knowledge in one person who understands and maintains the workflow.

What happens if exactly that person gets sick, quits or simply gets other priorities? In practice, teams running self-built AI solutions spend a growing share of their time not on new topics but on maintaining and bug-fixing what already exists. This pattern is well documented across industries: a McKinsey/Oxford study of over 5,400 IT projects found an average budget overrun of 45%, while the actual value delivered was on average 56% below the original forecast. The study refers to large IT projects, but the same pattern shows up on a small scale too: “let's just automate order status” quickly turns into a system nobody fully understands any more.

Reality check 2: how unpredictable are token costs and model quality really?

Token costs are often downplayed in the make discussion, with the argument that more providers automatically mean lower prices. In practice, the opposite is true: providers betting on particularly powerful models tend to raise their prices to stay profitable themselves. A single day of vibe coding can quickly produce a three-figure bill without a single productive customer request being processed. If your business case calculates firmly with ticket costs but overlooks fluctuating token costs, you risk the numbers no longer adding up afterwards.

Then there's a second, rarely discussed effect: model changes don't automatically mean better quality. A newer model can even perform worse than its predecessor on a specific task such as intent recognition – a phenomenon known in model development as quality drift: recent research shows that version changes in language models regularly lead to such individual regressions, even when the average score across all tasks rises. So if you build yourself, you need to keep an eye not just on costs but also on dedicated quality control for every model change, including a staging environment and test process. How much weight costs and governance around AI tooling now carry is shown by a recent Gartner forecast from June 2026: the analysts expect AI coding costs per developer to exceed the average developer salary by 2028, driven by rising token consumption and usage-based pricing models.

Reality check 3: does a self-built chatbot really learn as it goes?

A common assumption: once all company knowledge sits in a language model like Claude, the bot will automatically get better the more customers talk to it. Technically, that's not correct. Without your own fine-tuning on a separate training infrastructure, the quality of an LLM stays constant. It answers requests based on the stored knowledge base but doesn't learn from past chat histories. If you expect answer quality to improve over time, you need either a fine-tuning infrastructure that most standard models don't offer, or an architecture based on retrieval-augmented generation (RAG) rather than model knowledge.

The second, often overlooked question: do you really want the entire customer history, including personal and sometimes sensitive data, to sit permanently in a general AI model? That's exactly where the next point comes in.

What GDPR and EU AI Act risk do you take on if you build in-house?

As soon as a system processes real customer data – accounts, orders, refunds or sensitive cases – the GDPR applies from the very first request. If you build in-house, you effectively become your own AI provider, including responsibility for data processing agreements, subprocessor documentation and technical safeguards. That's not a theoretical risk: according to the CMS GDPR Enforcement Tracker, GDPR fines have exceeded €6 billion since 2018, as of March 2026.

The EU AI Act tightens things further: from August 2, 2026, new transparency obligations apply – users must be able to clearly recognize that they're talking to an AI system, as set out in Art. 50 EU AI Act (Regulation 2024/1689). melibo explains the exact obligations per risk class in the glossary entry on EU AI Act risk categories and in the detailed blog article on the EU AI Act in customer service. If you build yourself, you have to set up all this proof, these processes and this documentation entirely on your own. If you buy a SaaS platform, you usually get the DPA, subprocessor list and labeling as part of the offer – but you should have the provider confirm this in writing rather than assume it.

Another often underestimated risk factor of self-built systems: hallucinations. Every AI project has a certain base rate of made-up or wrong answers. How high this risk is and how it can be contained technically is explained in the melibo article AI hallucinations in customer service.

Is the lock-in effect really bigger when you buy than when you build?

A common objection to buying: if you purchase a SaaS solution, you become dependent on the provider and its prices. That's partly true – every solution, whether make or buy, ultimately depends on the prices of the underlying LLMs. The crucial difference isn't whether a dependency exists, but how professionally it's managed.

A specialized provider usually employs several people who do nothing but evaluate models, switch between providers like OpenAI and Anthropic and pick the right model size for each task – a simple model for ticket categorization, a more powerful one for complex complaint replies. If you build yourself, you have to build up this architecture, know-how and capacity internally and fund it permanently. The lock-in effect when buying is real, but usually much weaker, because the risk is managed professionally rather than resting with a single internal person. That's an assessment, not a blank check: check specifically how each provider handles model changes before relying on it.

When does make still pay off – and when is buy clearly the answer?

Building in-house isn't wrong in principle, but it only pays off for a smaller share of companies. Make mainly makes sense if several of these points apply at the same time:

• AI or automation is your core product, not just a supporting process.
• You have strict compliance requirements that mandate on-premise hosting.
• A dedicated team of more than two people is responsible full time exclusively for model selection, maintenance and quality control.
• You can handle a hallucination rate in AI operations professionally, including monitoring and workarounds.

If none or only one of these points applies, a specialized SaaS platform is usually the more economical choice: providers compete with each other and are therefore forced to keep delivering the best value for money. How AI agents fundamentally differ from simple Agent Assist solutions, and from what ticket volume getting started pays off at all, is shown in the melibo article At what ticket volume does an AI agent pay off?

Conclusion

A self-built AI chatbot looks cheap at first; the real bill only comes later: through maintenance, fluctuating token costs and growing scope. So the right question isn't whether a prototype can be built, but whether the system can still be run and maintained reliably in twelve months without depending on a single person. You'll have a dependency on AI providers either way, whether you build or buy – the only question is whether it's managed professionally or stays entirely within your own team. If your company meets the four criteria above, make is a legitimate choice. For most companies without a dedicated AI team, however, investing properly once is often the more sustainable decision than maintaining it yourself forever.