Building an AI tutor: the underestimated challenges
Setting up a system that answers student questions around the clock, connecting it to your own LMS, keeping it stable through exam season and then develop it further year after year. Once a university seriously considers an AI tutor, one basic question comes up early: build it yourself or license a finished solution?
This question is rarely purely technical. It decides staffing, budget and who carries responsibility for day-to-day operation. We write this as a provider and cannot be neutral here. Even so, we lay out the trade-off as factually as possible, including the cases where building in-house is the right decision.
The benchmark, and when building in-house pays off
Build means the university develops the AI tutor itself or has it developed, hosts it and operates it permanently under its own responsibility. Buy means the university licenses an existing solution and receives operation, maintenance and further development as a service from the provider. Both paths lead to the same visible result, a tutor students use. The difference sits underneath: with whom development skill, operational load and cost risk permanently rest.
One point shapes the whole trade-off: an in-house build does not compete with a specialised provider, it competes with ChatGPT, Gemini and NotebookLM. That is the standard of experience students use every day and against which they measure every in-house tool. If the in-house build is even slightly clumsier or weaker, students simply switch to those systems, and the invested time is lost, because the tool exists but is not used. For the university this means the real competition is one over usability, and it does not stop.
An in-house build has real advantages. It can cover use cases not available on the market, secures full data sovereignty and builds AI and software expertise inside the institution. Technically almost every hurdle can be overcome, and many universities bring the necessary skills. For the path to pay off, though, several conditions must be met at the same time: permanently available AI and software development expertise, not only for the project phase, and a multi-year budget for development and operation.
The decisive condition is strategic, not technical: whether an in-house AI tutor matters so much to the university that it deliberately wants to differentiate itself through it. That question belongs at the start of the deliberation, not the end. A good fit when clear strategic differentiation is wanted, expertise and budget are permanently in place and special use cases exceed the market. A weaker fit when the tutor is mainly meant to be a solid standard tool and staff are already fully occupied.
What planning routinely underestimates
The most common planning mistake is to judge the in-house build by the first working demo. A prototype that works in 80 percent of cases is not yet fit for production, and the last 20 percent cost significantly more than the first 80. Four items are almost always set too low.
Model updates: language models change constantly, several major updates a year are the norm, and each one requires fresh regression testing of your own prompts. Part of the capacity therefore goes permanently into keeping existing features working.
Ongoing operation: the largest item is not the API bill but the time of skilled staff for operation, monitoring and responding to incidents. The tangible costs are staff costs, and they recur every year.
Data protection and infrastructure: whoever self-hosts takes on full responsibility for data protection, for connecting to the single sign-on of the German university federation and for LMS integration, for example with Moodle via LTI 1.3, the open integration standard from 1EdTech. Together this is a permanent operational task, not a one-off development.
Hallucination control: as a rule, an AI tutor should be designed so that it minimises invented answers and anchors its responses in approved, course-related content. One established way to do this is RAG (retrieval-augmented generation): the system looks up a defined knowledge base, for example the uploaded course materials, and bases its answer on what it finds there rather than on the model alone. Keeping that knowledge base clean across all courses is classic software engineering work.
AI tutors are used seasonally. During exam season demand quickly rises to 10 to 20 times normal operation. There are two ways to handle this load profile, and both have their catches. On your own hardware it means keeping GPU capacity available at that same multiple, capacity that sits largely idle the rest of the year. In the cloud scaling is technically solved, but cost planning becomes the problem, because features such as podcast generation or AI avatars consume a multiple of the tokens, in some cases ten times as many. For the university this means reliable operating-cost forecasts are hard with an in-house build, regardless of the chosen path. With a licensed solution this planning risk sits with the provider.
Product, staffing and the decision
Whether an in-house build keeps meeting the standard of ChatGPT and others over time depends less on tokens, GPUs and data storage than on the product work behind it. The hardest part is building something students actually want to use. That requires continuous work: regular user interviews, surveys and analysis of real usage behaviour. This work never ends and is the difference between a tool that exists and one that is used.
To build a system that comes close to the current capabilities of specialised solutions takes, in our experience, three to four full-time people permanently, roughly three developers and one product manager. This point is often overlooked because it is assumed existing staff can do it on the side. In practice the roles are either newly created or pulled from other tasks that then fall behind. As an employer, staff costs for this come to roughly 200,000 to 300,000 euros a year, plus infrastructure, GPU or cloud costs and scaling reserves.
Building an AI-supported learning system in-house is technically feasible. The decisive question is not whether a university can build such a system, but whether it wants to operate it year after year, keep it competitive against ChatGPT and others and develop it as a product.
Rather than a fixed total figure, in our view the cost structure is more telling. An in-house build ties up permanent staff and operating costs plus scaling costs that are hard to plan, and the cost risk stays inside the institution. A licensed solution creates recurring, predictable licence costs, while the scaling and operating risk sits with the provider. The question is therefore less which path is cheaper in absolute terms and more who should carry the cost risk.
For universities that deliberately want to differentiate themselves strategically through their own AI tutor and can provide expertise and budget permanently, building can be the right path. For most others a licensed solution is faster to go live and lower in risk in day-to-day operation. Between the two paths there are also middle ways, for example an adaptable solution or a time-limited pilot before the fundamental decision. The honest groundwork is to answer this fundamental question before the first demo is built, not after.
