Goal — Learning Bavarian as it is spoken: a language-learning app for a dialect with no official standards.

LearnBavarian is an AI-assisted language-learning app for the Bavarian dialect — in production with a payment model, EU hosting and a complete GDPR architecture, shipped in 10 language versions.

What matters for the consulting is not the app but what its day-to-day operation demonstrates: an approval architecture instead of autopilot, GDPR handled in layers instead of by blanket rule, provider independence as a building principle — the same decisions every company faces when adopting AI, already made here and proven in live operation.

Dialect cannot be claimed, only measured.

For language models, Bavarian is an edge case: little training material, many variants, no standard. So nothing here is decided by feel. Every character runs through a test series against fixed criteria — authenticity of the dialect, voice, response time, reproducibility of the same input.

Models were set against each other and rejected with reasons: one ran into a repetition loop, a second delivered good language at an unacceptable response time, the third had weaknesses that were reproducible and therefore correctable. Only the third went into operation.

One Bavarian term was classified wrongly, and identically so, by 2 independent models. That is not a model defect but a gap in the training material itself — and no better prompt closes it. The consequence was not another attempt at prompting but the move to fine-tuning with our own data.

The quality of the dialect check is kept as a metric, not as an impression: F2 value 89.4 % in the cleaned run of 15 May 2026, taken with our own eval script over a fixed test corpus. The test series are numbered consecutively and documented, including where the result was inconvenient.

Whoever talks to users gets tested by users.

Every character in the app has its own section in the prompt that covers exactly one case: the attempt to override its identity or to defeat its instructions. The answer to that is fixed — a calm boundary, no escalation, no playing along.

These cases are not only in the prompt, they are in the test corpus. Inputs that begin harmlessly and carry a smuggled instruction in mid-sentence are part of the standing test set — the validator has to flag them as an attempt at manipulation, not carry them out. What is not tested counts here as unchecked.

The same attitude carries into the consulting: an assistant that has customer contact needs an attack test series before it goes online — not afterwards.

No model is the right one for everything — and none is free.

Every task gets the model it needs, not the largest one available. The assignment sits in a routing matrix: one primary model and one fallback per role. It is generated from a single source; if the documentation diverges from it, the commit fails. Small and partly free models run the simple, frequent tasks, the strong ones the questions of judgement.

Costs are not estimated, they are calculated. Every call is recorded with its token count and price, valued against a stored price table and charged against a daily budget that is reported as a metric. If a provider runs into a block, the fallback takes over with a wait rather than blind retrying.

The decisions of principle are documented with the alternatives they rejected: a single provider for everything was rejected over response time and missing caching, the direct route to a provider over cost. Those reasons can be read back, so that a later change knows what it is deciding against.

This is the point at which AI projects in companies usually derail: not on the technology, but on unlimited calls with no assignment, no ceiling and no measurement. Whoever assigns per task, caps and measures from the start knows their operating costs before the first invoice arrives.