Was kostet ein KI-MVP in Österreich 2026?

Ehrliche Antwort zuerst: Die meisten KI-MVPs, die wir in Österreich sehen, landen irgendwo zwischen €15.000 und €120.000, und die Streuung innerhalb dieser Spanne wird fast ausschließlich davon getrieben, was du tatsächlich baust, nicht davon, wer es baut. Ein dünnes KI-Feature, das du an ein bestehendes Produkt schraubst, ist ein anderes Tier als ein KI-natives Produkt, bei dem das Modell der ganze Punkt ist. Unten bekommst du eine Tabelle mit ehrlichen Spannen, was die Zahl rauf- oder runtertreibt, und wo sich das billigste Angebot als das teuerste entpuppt.

Jede Zahl hier ist eine Schätzung aus dem, was wir in der Praxis haben entstehen sehen, kein fixes Angebot und kein Umfragedurchschnitt. Behandle die Spannen als Bereiche, an denen du Angebote auf Plausibilität prüfst, und hol dir dann eine gescopte Zahl für deinen konkreten Fall. Wer eine präzise Zahl nennt, bevor er deine Daten und deine Integrationen versteht, rät auch nur.

Was kostet ein KI-MVP?

Hier ist die Tabelle, die wir im ersten Gespräch mit Gründern durchgehen. Die Spannen sind absichtlich weit, weil die ehrliche Version dieser Antwort weite Spannen hat. Die Zahlen sind Schätzungen, keine Angebote.

Wenn dein Projekt sauber in eine Zeile fällt, nimm diese Spanne. Die meisten Projekte sitzen zwischen zwei Zeilen, und genau deshalb ist ein Scoping-Gespräch mehr wert als ein Rechner.

Was die Kosten rauf- oder runtertreibt

Die Stufe legt die Größenordnung fest. Diese Faktoren entscheiden, wo du innerhalb der Spanne landest, und ob du oben durchbrichst.

• Datenbereitschaft. Saubere, zugängliche, gut strukturierte Daten sind der größte einzelne Hebel. Können wir deine Daten am ersten Tag lesen, sitzen die Kosten unten in der Spanne. Müssen wir sie erst extrahieren, bereinigen und labeln, kann diese Arbeit allein die Hälfte des Budgets sein.
• Anzahl der Integrationen. Jedes externe System, mit dem das MVP reden muss, dein CRM, deine Abrechnung, eine Drittanbieter-API, bringt Umfang, Error-Handling und Tests mit. Eine Integration ist billig. Fünf sind ein Projekt im Projekt.
• Compliance-Umfang. Personenbezogene Daten, regulierte Branchen oder alles, was den EU AI Act berührt, hebt den Boden an. Die Kontrollen sind nicht optional und kosten echte Engineering-Zeit.
• Modell- und Infra-Entscheidungen. Eine gehostete API auf fremdem Modell ist billig im Start. Self-Hosting, Fine-Tuning oder alles, was GPUs braucht, bringt dich schnell in eine andere Kostenstruktur.
• Wie viel ist wirklich neu vs CRUD. Ein großer Teil jedes KI-MVP ist gewöhnliche Software: Auth, Formulare, Dashboards, Abrechnung. Dieser Teil ist vorhersehbar. Der wirklich neue Teil, das, was noch niemand gebaut hat, ist dort, wo die Schätzung unscharf wird und das Budget Luft braucht.

Build vs Buy vs Fine-Tune

Die billigste Entscheidung, die du treffen kannst, ist, das nicht zu bauen, was du nicht bauen musst.

• Buy / API einbinden. Für die große Mehrheit der MVPs schlägt der Aufruf eines gehosteten Modells über dessen API alles andere. Du bekommst ein Frontier-Modell ohne Trainingskosten und zahlst nur, was du nutzt. Starte hier, außer du hast einen konkreten Grund dagegen.
• Build. Du baust immer das Produkt um das Modell herum: die Retrieval-Schicht, die Workflows, die Evaluation, die UI. Dort fließen dein Geld und deine Differenzierung tatsächlich hin.
• Fine-Tune. Die meisten MVPs sollten nicht fine-tunen. Es bringt Datensammlung, Training und Wartungskosten für einen Nutzen, den du meist erst messen kannst, wenn du echte Nutzung hast. Greif erst dann dazu, wenn Prompting plus Retrieval wirklich an die Wand gefahren ist und du Daten und Evaluation hast, die belegen, dass es geholfen hat. Für ein MVP ist das selten schon der Fall.

Die laufenden Kosten, die alle vergessen

Das Build-Budget ist die sichtbare Zahl. Die Betriebskosten sind die, die Gründer drei Monate nach Launch überraschen.

• Inferenz- und Token-Ausgaben. Jeder Request an ein gehostetes Modell kostet Geld, und im Skalieren summiert sich das schnell. Modell- und Architektur-Entscheidungen verändern diese Rechnung um eine Größenordnung, und genau deshalb verdient sie eine echte Entscheidung statt eines Defaults. Wir haben das in LLM-API-Kosten und der 2026er Architektur-Shift aufgeschlüsselt.
• Evaluation. Ein KI-Feature ohne Evaluation ist ein Feature, das du nicht sicher ändern kannst. Du brauchst einen Weg zu messen, ob ein Prompt- oder Modellwechsel die Dinge besser oder schlechter gemacht hat, und dieses Harness ist Teil der Betriebskosten, kein Nice-to-have.
• Monitoring. Modelle driften, Prompts verrotten, und Eingaben, die du dir nie vorgestellt hast, kommen in Woche zwei. Outputs in Produktion zu beobachten ist laufende Arbeit.
• Retraining und Updates. Wenn du fine-getunt hast oder einen Retrieval-Index pflegst, veraltet dieser Inhalt und muss aufgefrischt werden. Plane es von Anfang an ein.

Finanzierung in Österreich

Wenn du in Österreich baust, kann ein wesentlicher Teil des Builds gefördert werden, und das ist einer der echten Vorteile, hier zu bauen. Die drei, die du kennen musst:

• Forschungsprämie. 14 Prozent Forschungsprämie auf qualifizierende F&E-Ausgaben, ausbezahlt als Cash-Rückerstattung unabhängig vom Gewinn. Echte KI-Entwicklung qualifiziert sich meist. Die Mechanik haben wir in der Forschungsprämie für Softwareentwicklung behandelt.
• FFG. Die Österreichische Forschungsförderungsgesellschaft fördert F&E-Projekte über Zuschüsse und Darlehen, oft der größte Hebel für wirklich neue Arbeit.
• aws. Austria Wirtschaftsservice bietet Zuschüsse, Garantien und Preseed-Unterstützung für Unternehmen in früher Phase.

Diese lassen sich stapeln, und sie gut zu stapeln verändert die echten Kosten eines MVP erheblich. Wie das geht, haben wir in aws, FFG und den Rest stapeln durchgespielt.

"Ein KI-MVP ist größtenteils gewöhnliche Software mit einem harten Teil in der Mitte. Verbrannt werden die Gründer, die für den harten Teil gezahlt und vergessen haben, dass die gewöhnliche Software auch produktionsreif sein muss."

Wenn die billigste Option die teuerste ist

Es gibt immer ein billigeres Angebot. Manchmal ist es billiger, weil das Team schlanker und schneller ist. Oft ist es billiger wegen dem, was still weggelassen wurde, und das ist die Rechnung, die spät kommt.

• Keine Evaluation. Die Demo sieht super aus. Dann kannst du nicht sagen, ob deine nächste Änderung irgendetwas verbessert hat, und du fliegst blind beim einen Teil, der es zu einem KI-Produkt macht.
• Keine QA an der gewöhnlichen Software. Das Modell läuft; die Auth, Eingabevalidierung und das Error-Handling drumherum nicht. Diese Lücke kostet nach dem Launch weit mehr als davor.
• Umfang gekürzt, um eine Zahl zu treffen. Die Integration, die gestrichen wurde, damit das Angebot passt, ist meist die, die deine Nutzer am meisten brauchten. Jetzt ist sie ein v2-Projekt statt eines Posten.
• Die falsche Build/Buy-Entscheidung. Geld, das für das Fine-Tuning eines Modells ausgegeben wurde, das ein API-Aufruf bedient hätte, ist Geld, das du nicht zurückbekommst.

Nichts davon heißt, kauf die teuerste Option. Es heißt, vergleiche Angebote nach dem, was tatsächlich drinsteckt, nicht nur nach der Summe ganz unten.