Kann KI eine App mit Datenbank bauen? Ehrliche Antwort
Kann KI eine App mit Datenbank bauen? Ehrliche Antwort
Ja. Eine App, die Daten speichert, lesen, ändern und filtern lässt, gehört zu den Fällen, die ein KI-Builder gut abdeckt. In Zugo übernimmt Supabase Datenbank, Anmeldung und Dateien. Zuverlässig entstehen Kundenlisten, Buchungen, Lagerbestände und interne Werkzeuge. Schwieriger wird es bei verschachtelten Rechten und gewachsener Fachlogik.
Der Unterschied zwischen einer Seite und einer Datenbank-App ist größer, als er von außen aussieht. Eine Seite zeigt, was Sie hineingeschrieben haben. Eine App verwaltet, was andere Menschen hineinschreiben, und braucht dafür ein Datenmodell, Rechte und eine Vorstellung davon, was bei falschen Eingaben passiert.
Was ist eine App mit Datenbank überhaupt?
Praktisch immer dasselbe Muster: Es gibt Einträge, es gibt Formulare, mit denen man sie anlegt, es gibt Listen, in denen man sie wiederfindet, und es gibt Personen mit unterschiedlichen Rechten darauf. Ob das Ding Kundenverwaltung, Buchungssystem oder Inventarliste heißt, ändert an diesem Muster wenig.
Deshalb lassen sich solche Apps gut erzeugen. Der Builder muss keine Kreativität aufbringen, sondern ein bekanntes Muster auf Ihre Begriffe anwenden. Aus Kunde, Auftrag und Rechnung wird eine Struktur, aus dieser Struktur werden Formulare und Ansichten.
Der schwierige Teil liegt nicht im Bauen, sondern im Beschreiben. Wer sagt, er wolle eine App für seine Kunden, bekommt eine plausible Kundenliste, die vielleicht nicht seine ist. Wer sagt, welche Felder ein Kunde hat, was mit ihm verknüpft ist und wer ihn sehen darf, bekommt beim ersten Versuch etwas Brauchbares.
Was übernimmt Supabase in einem Zugo-Projekt?
Supabase ist die feste Integration für alles, was gespeichert wird: die Datenbank selbst, die Anmeldung von Nutzern und die Ablage von Dateien wie Bildern oder Dokumenten. Sie müssen dafür keinen Server einrichten und keine Tabellen von Hand anlegen.
Daneben stehen die übrigen Integrationen, die in Datenbank-Apps regelmäßig gebraucht werden: Stripe für Zahlungen und Abonnements, Resend für E-Mails wie Bestätigungen und Benachrichtigungen, Google Analytics für Statistik, GitHub für den Export der Quellen und Vercel für ein Deployment im eigenen Konto.
Diese Trennung ist wichtig für die Frage, wem etwas gehört. Das Projekt entsteht im Builder, die Daten liegen in der angebundenen Datenbank, und der Quelltext lässt sich exportieren. Sie sitzen also nicht auf einem Datenbestand, an den Sie nur über ein einziges Werkzeug herankommen. Was die Anbindung genau umfasst, steht in KI-App-Builder mit Supabase.
Welche Datenbank-Apps entstehen zuverlässig, welche nicht?
Die ehrliche Einordnung nach Aufwand, nicht nach Wunschdenken.
| Vorhaben | Wie gut es entsteht | Was Sie einplanen sollten |
|---|---|---|
| Kontakt- und Kundenliste mit Notizen | sehr gut | Felder vorab benennen |
| Buchungen und Termine | gut | Regeln zu Zeitfenstern und Absagen |
| Lager und Inventar | gut | Was bei Bestand null passiert |
| Aufgaben, Tickets, Kanban | sehr gut | Statuswerte festlegen |
| Formulare mit Auswertung | sehr gut | Pflichtfelder benennen |
| Mitgliederbereich mit Inhalten | gut | Rechte je Rolle |
| Rechnungen mit Steuerlogik | mittel | mehrere Änderungen einplanen |
| Provisions- und Tarifmodelle | mittel bis schwer | Regeln einzeln beschreiben |
| Verschachtelte Rechte über viele Rollen | schwer | schrittweise aufbauen |
| Anbindung an ein altes Warenwirtschaftssystem | nicht der Fall des Builders | Entwickler einplanen |
Die Grenze verläuft nicht zwischen einfach und komplex, sondern zwischen benennbar und gewachsen. Eine komplizierte Regel, die Sie in drei Sätzen erklären können, entsteht. Eine einfache Regel mit zwanzig Ausnahmen aus zwanzig Jahren Betriebspraxis entsteht nicht in einem Durchgang.
Wie beschreibe ich das Datenmodell, damit es passt?
Vier Angaben genügen, und sie sparen die meisten Korrekturschleifen.
Erstens die Objekte. Nennen Sie die Dinge, um die es geht, in Ihrer eigenen Sprache: Kunde, Auftrag, Fahrzeug, Termin, Schüler. Der Builder übernimmt diese Begriffe, und die App spricht danach die Sprache Ihres Betriebs statt eine allgemeine.
Zweitens die Felder je Objekt. Ein Kunde hat Name, Firma, Telefonnummer, E-Mail, Notiz und ein Anlagedatum. Das klingt banal, ist aber der Unterschied zwischen einer passenden und einer generischen Struktur.
Drittens die Beziehungen. Ein Kunde hat mehrere Aufträge, ein Auftrag gehört zu genau einem Kunden, ein Auftrag kann mehrere Positionen enthalten. Diese drei Sätze sind bereits ein Datenmodell.
Viertens die Sicht darauf. Wer meldet sich an, was darf diese Person sehen und was ändern? Ein Vertriebsmitarbeiter sieht seine eigenen Kunden, die Geschäftsführung sieht alle. Ohne diese Angabe bekommen alle dasselbe, und das ist selten gewollt.
Was kostet der Aufbau einer solchen App in Credits?
Abgerechnet wird nach Aktionen, nicht nach Datenmenge.
| Aktion | Credits | Im Hi-Fi-Modus |
|---|---|---|
| Änderung an einem bestehenden Projekt | 3 | 6 |
| Frischer Build | 6 | 12 |
| Mehrseitige Plattform | 12 für die ersten drei Seiten, danach 3 je weiterer Seite | doppelt |
Eine Datenbank-App ist fast immer eine mehrseitige Plattform, weil sie mindestens Übersicht, Detailansicht und Formular braucht. Rechnen Sie also mit dem Plattformpreis für den Start und danach mit Änderungen, während Sie das Modell schärfen.
Free enthält 5 Credits, Pro kostet 25 $ im Monat mit 200 Credits, Business kostet 99 $ im Monat mit 800. Zweihundert Credits entsprechen etwa 16 mehrseitigen Plattformen oder 33 Builds oder 66 Änderungen im Monat. Ein ehrlicher Hinweis: 5 Credits liegen unter den 6 für einen einzelnen Build, der kostenlose Tarif zeigt also die Oberfläche und trägt kein fertiges Projekt. Abgerechnet wird in US-Dollar.
Wie steht es um Anmeldung und Zugriffsrechte?
Anmeldung gehört zu Supabase und ist damit Teil des Standardwegs. Nutzer registrieren sich, melden sich an, und die App weiß, wer gerade davorsitzt. Details dazu stehen in Kann KI einen Login bauen.
Der anspruchsvollere Teil sind Rechte. Solange es zwei Rollen gibt, etwa angemeldet und Verwaltung, ist die Sache übersichtlich. Sobald Rechte von Beziehungen abhängen, wird es zur eigentlichen Arbeit: Ein Trainer sieht nur die Kurse, denen er zugewiesen ist, und darin nur die Teilnehmer, die zugestimmt haben.
Solche Regeln entstehen über mehrere Änderungen. Der praktikable Weg ist, mit der einfachsten Fassung zu starten, sie zu prüfen und die Ausnahmen einzeln zu ergänzen. Wer alle Regeln in einen einzigen Prompt packt, bekommt ein Ergebnis, das er nicht mehr überprüfen kann.
Prüfen Sie Rechte immer aus der Sicht der schwächsten Rolle. Legen Sie ein Testkonto an, melden Sie sich damit an und versuchen Sie bewusst, etwas zu sehen, was Sie nicht sehen dürften. Diese fünf Minuten sind bei jeder Datenbank-App gut investiert.
Was passiert mit den Daten, wenn ich die App ändere?
Das ist die Frage, die vor dem ersten echten Datensatz geklärt gehört. Änderungen betreffen die App, nicht die vorhandenen Einträge: Ein neues Feld erscheint, ein umbenannter Bereich heißt anders, eine Ansicht bekommt einen Filter.
Heikel wird es dort, wo sich die Struktur selbst ändert, etwa wenn aus einem Textfeld eine Auswahlliste wird oder ein Objekt in zwei aufgeteilt wird. Solche Umbauten sind auch für Entwickler die unangenehmen, und sie sind der Grund, warum es sich lohnt, das Modell vor dem Echtbetrieb einmal ernsthaft durchzudenken.
Zwei Gewohnheiten helfen dauerhaft. Erstens: Probieren Sie strukturelle Änderungen mit Testdaten, bevor echte Einträge betroffen sind. Zweitens: Exportieren Sie den Datenbestand regelmäßig, so wie Sie es bei jeder anderen Software auch täten. Vor der Übergabe prüft zwar eine Sandbox, ob ein Build startet, aber sie ersetzt keine Sicherung.
Wo sind die Grenzen?
Drei, klar benannt. Sehr spezifische Fachlogik entsteht über mehrere Änderungen und nicht über einen einzigen Prompt. Rechnen Sie bei einem Tarifmodell oder einer Provisionsstaffel mit mehreren Durchgängen und einer Person, die das Ergebnis fachlich prüft.
Bei einem großen, langlebigen Produkt ersetzt der Builder kein Entwicklungsteam. Eine interne App für zwölf Kollegen ist etwas anderes als ein Produkt, das Tausende Kunden täglich benutzen und das über Jahre weiterentwickelt wird.
Und Anbindungen an bestehende Systeme sind der übliche Ausstiegspunkt. Wenn Daten aus einer vorhandenen Warenwirtschaft, einer Praxissoftware oder einer alten Datei mit gewachsener Struktur kommen sollen, planen Sie dafür einen Menschen ein. Über den GitHub-Export bekommt er den Quelltext, über Vercel läuft der Betrieb in Ihrem Konto.
Wie fange ich sinnvoll an?
Mit dem kleinsten nützlichen Ausschnitt. Nehmen Sie ein Objekt, seine Felder und eine Liste, bauen Sie das, tragen Sie zehn echte Datensätze ein und arbeiten Sie eine Woche damit. Sie werden nach dieser Woche eine deutlich bessere Beschreibung für alles Weitere haben als heute.
Danach ergänzen Sie in Änderungen: das zweite Objekt, die Beziehung dazwischen, die Rollen, die Auswertung. Es gibt 25 Vorlagen, davon 5 für Spiele, und ein passender Startpunkt spart den ersten Bau. Ein ausgearbeitetes Beispiel für diesen Weg steht in CRM mit KI bauen.
Eine einfache Seite steht in etwa einer Minute, eine mehrseitige Plattform braucht einige Minuten. Ausprobieren können Sie das auf zugo.dev, am besten mit dem Ausschnitt Ihres Vorhabens, den Sie ohnehin schon in drei Sätzen erklären können.