KI-App-Builder mit KI-Funktionen: was geht und was nicht

KI-App-Builder mit KI-Funktionen: was geht und was nicht

Hier gehören zwei Dinge auseinander. Zugo selbst ist um ein Modell herum gebaut: Sie beschreiben ein Projekt in Textform, und es entsteht. Eine fertige Anbindung, die ein Sprachmodell in Ihr eigenes Produkt einbaut, steht dagegen nicht in der Liste. Solche Funktionen entstehen über den Code-Export und einen eigenen Anbieter.

Das ist keine vorläufige Lücke, die dieser Text nur schlecht erklärt, sondern eine Festlegung. Wer sie früh kennt, plant die Kosten richtig und wählt die passende Reihenfolge.

Worin unterscheidet sich die bauende KI von KI im Produkt?

Die Verwechslung entsteht durch ein Wort in zwei Rollen, und sie kostet Menschen regelmäßig Wochen.

Erste Rolle: Das Modell als Werkzeug beim Bauen. Sie schreiben „Website für ein Yogastudio mit Kursplan und Anmeldeformular", und wenig später stehen funktionierende Seiten. Das Modell arbeitet hier beim Erstellen. Im ausgelieferten Projekt steckt es nicht: Die erzeugte Website ist gewöhnlicher Code, der beim Besucher ohne jeden Modellaufruf öffnet.

Zweite Rolle: Das Modell als Teil des Produkts. Ein Assistent im Kundenkonto, automatisch erzeugte Produkttexte, die Auswertung eines hochgeladenen Dokuments. Hier wird das Modell jedes Mal aufgerufen, wenn ein Besucher die Funktion benutzt, und jeder dieser Aufrufe wird jemandem in Rechnung gestellt.

Technisch und wirtschaftlich sind das grundverschiedene Dinge. Das Erste passt in die Credits des Builders und ist vorhersehbar. Das Zweite bedeutet laufende Kosten, die mit der Nutzerzahl mitwachsen, und verlangt einen Anbieterschlüssel, Nutzungsgrenzen und einen Schutz dieses Schlüssels vor Fremden.

Welche Anbindungen gibt es tatsächlich?

Die Liste ist endlich, und sie vollständig zu nennen ist ehrlicher, als sie mit allgemeinen Worten zu umschreiben.

Ein Punkt „Sprachmodell in Ihrer Anwendung" steht dort nicht. Wenn Sie einen eingebauten KI-Assistenten im Produkt brauchen, planen Sie ihn über Code und nicht über einen Schalter in den Einstellungen.

Wie kommt trotzdem eine KI-Funktion ins eigene Projekt?

Der gangbare Weg hat vier Schritte und beruht darauf, dass das Projekt Ihnen gehört.

Bauen Sie zuerst im Builder alles, was nichts mit dem Modell zu tun hat: Seiten, Formulare, Anmeldung, Datenbank, Zahlungen. Das ist der mengenmäßig größte Teil der Arbeit, und die Generierung erledigt ihn schnell.

Exportieren Sie danach die Quellen nach GitHub. Ab diesem Moment liegt ein normales Projekt im Repository, und alles Weitere unterscheidet sich in nichts von gewöhnlicher Entwicklung. Was dabei genau im Repository landet, steht in KI-App-Builder mit GitHub.

Anschließend ergänzt ein Entwickler den Aufruf des gewählten Anbieters. Der Schlüssel liegt auf der Serverseite und nicht im Code der Seite: Ein Schlüssel, der im Browser landet, ist per Definition öffentlich, und Fremde finden ihn schneller, als Sie es bemerken.

Zuletzt läuft das Projekt auf Ihrer Infrastruktur, etwa über Vercel. Die Reihenfolge ist wichtig: erst das Produkt, dann die Modellfunktion. Umgekehrt bauen Sie eine teure Funktion für ein Produkt, das es noch nicht gibt.

Was lässt sich ohne Modell zur Laufzeit lösen?

Bevor Sie einen Entwickler beauftragen, prüfen Sie, ob die Aufgabe wirklich ein Modell im laufenden Betrieb braucht. Ziemlich oft nicht.

Texte und Beschreibungen erzeugen Sie einmalig und legen sie fertig ins Projekt. Ein Katalog mit zweihundert Artikeln muss nicht bei jedem Seitenaufruf ein Modell befragen, wenn die Beschreibungen einmal geschrieben sind.

Auswahl und Filterung lösen sich meist mit einer gewöhnlichen Abfrage. „Zeig mir passende Angebote" ist häufiger eine Bedingung in Supabase als eine Modellanfrage, und diese Variante arbeitet schneller, billiger und vorhersehbar. Wie die Datenhälfte aufgebaut wird, steht in KI-App-Builder mit Supabase.

Personalisierte E-Mails lösen Vorlagen. Resend verschickt eine Nachricht mit eingesetztem Namen und Bestelldaten, und dafür braucht es kein Modell.

Die Regel ist einfach: Ein Modell zur Laufzeit lohnt sich dort, wo die Antwort nicht vorab berechenbar ist, weil sie von einer beliebigen Eingabe abhängt. Alles andere ist einmal erledigt billiger.

Welche Erwartungen an KI im Produkt gehen schief?

Vier Annahmen zerbrechen fast immer an der Praxis, und alle vier kosten Budget.

„Der Assistent beantwortet jede Frage zu unserem Produkt." Er beantwortet, was man ihm gegeben hat. Ohne Ihre Wissensbasis erfindet er Eigenschaften mit voller Überzeugung, und das ist schlechter als gar kein Assistent: Der unzufriedene Kunde kommt mit einem Zitat von Ihrer eigenen Seite.

„Das wird günstig, ein Aufruf kostet Bruchteile eines Cents." Diese Bruchteile multiplizieren sich mit der Zahl der Besucher und deren Versuchen. Eine gern genutzte Funktion wird genau dann zum spürbaren Kostenblock, wenn das Projekt zu wachsen beginnt.

„Das Modell ersetzt die Suche im Katalog." Meistens nicht. Eine Datenbankabfrage liefert eine exakte und wiederholbare Antwort, ein Modell eine plausible. Für einen Warenkatalog ist das ein grundsätzlicher Unterschied.

„Niemand wird das missbrauchen." Doch. Eine offene Funktion, die einen kostenpflichtigen Anbieter aufruft, zieht automatisierte Anfragen an, und ohne Begrenzung wächst die Rechnung ohne jeden Nutzen für Sie.

Was ist mit Datenschutz, wenn Kundendaten an ein Modell gehen?

Sobald Ihr Produkt Eingaben von Nutzern an einen Modellanbieter schickt, verlassen personenbezogene Daten Ihr System. Damit ist das eine Frage der Auftragsverarbeitung und nicht nur eine technische Entscheidung, und in der Datenschutzerklärung muss stehen, was mit diesen Daten geschieht.

Praktisch heißt das drei Dinge. Prüfen Sie, welche Vertragslage der Anbieter bietet und wo verarbeitet wird. Schicken Sie nur die Felder, die die Funktion wirklich braucht, statt den ganzen Datensatz. Und legen Sie fest, was protokolliert wird, denn Protokolle mit Kundeneingaben sind selbst wieder personenbezogene Daten.

Das ist eine Einordnung aus der Praxis und keine Rechtsberatung. Der Punkt für die Planung: Diese Fragen gehören vor die Entwicklung und nicht hinter den Start, weil sie die Auswahl des Anbieters beeinflussen.

Was kostet das?

Zwei Geldbeutel, die ständig vermischt werden.

Die Arbeit im Builder rechnet in Credits.

Free gibt 5 Credits, Pro kostet 25 $ im Monat mit 200 Credits, Business kostet 99 $ im Monat mit 800. Zweihundert Credits sind etwa 16 mehrseitige Plattformen oder 33 Builds oder 66 Änderungen, jeweils für eine Art von Aktion gerechnet. Beachten Sie: 5 Credits sind weniger als die 6 für einen Build.

Die Arbeit des Modells in Ihrem Produkt wird getrennt gerechnet und an den Anbieter gezahlt, den Ihr Entwickler wählt. Diese Kosten hängen an der Zahl der Aufrufe und wachsen mit dem Publikum. Planen Sie sie in die Produktrechnung ein, bevor die Funktion online geht.

Wie prüfe ich die Idee, bevor Code geschrieben wird?

Es gibt einen billigen Weg herauszufinden, ob eine Funktion gebraucht wird, und er sieht solange unseriös aus, bis er einen Monat spart.

Bauen Sie im Builder ein Formular, das die Anfrage eines Nutzers entgegennimmt und in der Datenbank ablegt. Das ist eine Standardaufgabe für die Supabase-Anbindung und kostet einen Build.

Beantworten Sie diese Anfragen in der ersten Woche von Hand. Sie lesen selbst, formulieren selbst und schicken die Antwort per Resend. Der Nutzer bekommt genau das Ergebnis, wegen dem er gekommen ist.

Nach einer Woche haben Sie drei Dinge, die niemand hat, der sofort Code geschrieben hat: echte Formulierungen statt ausgedachter, eine Zahl darüber, wie viele Menschen die Funktion überhaupt nutzen, und eine Sammlung guter Antworten, die später die Grundlage der Automatisierung ist.

Ziemlich oft endet diese Woche mit dem Ergebnis, dass keine Automatisierung nötig ist: Bei zehn Anfragen pro Woche ist Handarbeit billiger. Diese Erkenntnis kostet einen Build und spart ein Entwicklungsbudget.

Wo verläuft die ehrliche Grenze?

Drei Sätze, die gerade gesagt gehören.

Einen Knopf „KI-Assistenten hinzufügen" gibt es im Builder nicht. Wird Ihnen so etwas versprochen, geht es um ein anderes Produkt, und das klärt man besser vor der Zahlung.

Zugo ersetzt bei einem komplexen Produkt kein Entwicklungsteam. Eingebaute Modellarbeit ist genau so ein Fall: Schlüssel, Grenzen, Fehlerbehandlung und Missbrauchsschutz sind eine Ingenieursaufgabe und keine Formulierung im Prompt. Was der Builder darüber hinaus nicht abdeckt, steht in Was kann KI nicht bauen.

Spezifische Fachlogik entsteht über mehrere Änderungen und nicht über einen einzigen Satz. Und jeder Build wird vor der Übergabe in einer Sandbox gestartet: Was nicht öffnet, wird nicht ausgeliefert. Diese Prüfung sagt, dass das Projekt läuft, nicht dass die Funktion wirtschaftlich sinnvoll ist.

Was jetzt sinnvoll ist

Bauen Sie im Builder alles, was ohne Modell zur Laufzeit funktioniert, und sehen Sie nach, wie viel von der Aufgabe übrig bleibt. Oft ist es deutlich weniger als gedacht, und das Projekt startet früher.

Bleibt die Modellfunktion danach nötig, exportieren Sie den Code und binden mit einem Entwickler einen Anbieter an. Die erste Version bauen und den Rest der Arbeit abschätzen können Sie auf zugo.dev.