Kann KI Login und Benutzerkonten bauen? Was wirklich geht

Kann KI Login und Benutzerkonten bauen?

Ja. Registrierung, Anmeldung, Abmeldung und ein Bereich, den nur angemeldete Personen sehen: Das entsteht in Zugo aus einer Beschreibung in normalen Sätzen, technisch getragen von der Supabase-Anbindung. Verlässlich ist der Standardfall. Fein abgestufte Rollen, Freigaben zwischen mehreren Firmen und alles, was rechtlich heikel wird, entsteht über mehrere Änderungen statt über einen einzigen Prompt.

Der Rest dieses Textes zerlegt das Wort „Login“ in seine Bausteine, zeigt, welcher davon zuverlässig herauskommt und welcher Ihre Aufmerksamkeit braucht, und nennt die Kosten in Credits. Das Kapitel über die typischen Schwachstellen ist das wichtigste: Eine Anmeldung, die aussieht wie eine Anmeldung, ist noch keine, die hält.

Was steckt eigentlich hinter dem Wort „Login“?

„Login“ klingt nach einer Sache und besteht aus fünf. Wer sie auseinanderhält, formuliert bessere Prompts und findet Fehler schneller, weil er weiß, welcher Baustein gerade versagt.

Die ersten vier Bausteine sind bei jedem Projekt gleich, egal ob Vereinsportal oder Kundenbereich einer Steuerkanzlei. Sie sind gelöste Probleme, und genau deshalb kommen sie aus einem Generator brauchbar heraus.

Der fünfte ist bei jedem Projekt anders. „Ein Mandant sieht nur seine eigenen Dokumente“ ist eine Regel über Ihre Daten, nicht über Anmeldeformulare. Hier verdient ein Projekt sein Geld, und hier lohnt sich Ihre Sorgfalt.

Wie entsteht die Anmeldung technisch?

Über Supabase. Der Dienst bringt Datenbank, Anmeldung und Dateiablage mit, und das Projekt, das Zugo baut, spricht mit ihm statt selbst Passwörter zu verwalten. Ihre Nutzerdaten liegen damit in Ihrem eigenen Supabase-Projekt, nicht in der generierten Seite.

Das hat eine praktische Folge, die viele überrascht: Der Login gehört Ihnen auch dann noch, wenn Sie das Frontend eines Tages wegwerfen. Welche Anmeldewege Sie anbieten und wie streng die Passwortregeln sind, entscheiden Sie in den Einstellungen Ihres Supabase-Projekts, nicht im Prompt.

Für Mails rund um die Anmeldung gibt es die Resend-Anbindung: Bestätigung nach der Registrierung, Link zum Zurücksetzen des Passworts, Benachrichtigungen. Wer eine eigene Domain verbunden hat, schickt diese Mails von der eigenen Adresse statt von einer fremden. Wie die Domain drankommt, steht in KI-App-Builder mit eigener Domain.

Wie formuliere ich das im Prompt?

Nennen Sie die Rollen und die Regel, nicht das Gefühl. „Mit Login“ ist zu wenig. Ein Satz darüber, wer nach der Anmeldung was zu sehen bekommt, verändert das Ergebnis deutlich stärker als drei Sätze über die Optik.

Baue ein Kundenportal für eine Physiotherapie-Praxis.
Anmeldung mit E-Mail und Passwort über Supabase.
Nach dem Login sieht ein Patient nur seine eigenen Termine.
Das Praxisteam sieht alle Termine und kann neue anlegen.
Ohne Anmeldung ist nur die Startseite erreichbar.
Alle Texte auf Deutsch, Anrede Sie.

Sechs Zeilen, davon vier über Rechte. Genau diese Verteilung fehlt in den meisten Prompts. Sie können das auch in zwei Schritten machen: erst die Seite bauen, dann die Anmeldung als Änderung ergänzen. Diese Reihenfolge ist oft die günstigere, weil eine Änderung weniger kostet als ein frischer Build. Wie man Prompts allgemein schärft, behandelt Wie schreibe ich einen guten Prompt.

Was kostet ein Projekt mit Benutzerkonten?

Nichts anderes als ein Projekt ohne. Abgerechnet werden Aktionen, nicht Funktionen, und ein Login ist keine Extraposition auf der Rechnung.

Die Tarife: Free enthält 5 Credits, Pro kostet 25 $ im Monat mit 200 Credits, Business 99 $ im Monat mit 800 Credits. Zweihundert Credits sind, wenn Sie nichts anderes damit tun, 66 Änderungen oder 33 Builds oder rund 16 mehrseitige Plattformen. Abgerechnet wird in US-Dollar.

Rechnen Sie beim Startguthaben mit: 5 Credits reichen für eine Änderung an einem bestehenden Projekt, nicht für einen kompletten Neubau, weil der 6 kostet. Ein Portal mit Anmeldung ist selten nach einem Durchgang fertig. Planen Sie zwei bis drei Änderungen ein, bis die Rechte sitzen.

Wo scheitert generierter Login-Code am ehesten?

An vier Stellen, und keine davon sieht man dem Bildschirm an. Deshalb steht hier die Fehlerklasse und nicht ein Beispielprojekt.

Die Rechteprüfung sitzt an der falschen Stelle. Ein Menüpunkt wird ausgeblendet, aber die Daten dahinter sind weiter abrufbar. Sichtbarkeit ist keine Berechtigung. Verlassen Sie sich darauf, dass die Regel in der Datenbank steht, nicht nur in der Oberfläche, und formulieren Sie das ausdrücklich.

Sonderfälle fehlen. Eine bereits vergebene E-Mail, ein abgelaufener Rücksetzlink, zweimal geklicktes Absenden. Der Hauptweg funktioniert, die Abzweigungen enden im Nichts oder in einer Fehlermeldung, die niemand versteht.

Rollen überschneiden sich. Sobald es mehr als zwei Rollen gibt, entstehen Fragen, die im Prompt gar nicht beantwortet wurden: Darf eine Assistenz fremde Termine löschen oder nur ansehen? Ein Modell rät hier, und es rät oft großzügig.

Rechtliches bleibt liegen. Ein Login sammelt personenbezogene Daten. Datenschutzerklärung, Impressum, Löschkonzept, Auftragsverarbeitung: Das sind Ihre Pflichten, und ein Builder erledigt sie nicht. Wie sicher Ihre Daten liegen, behandelt Sind meine Daten sicher genauer.

Was prüfe ich, bevor das Portal live geht?

Legen Sie zwei Testkonten an und arbeiten Sie die Liste von unten nach oben durch. Die meisten Mängel zeigen sich in zehn Minuten, wenn man gezielt danach sucht.

• Mit Konto A anmelden, den Datensatz von Konto B direkt über die Adresszeile aufrufen. Erscheint er, ist die Rechteprüfung nur Kosmetik.
• Passwort zurücksetzen und die Mail wirklich abwarten, statt den Ablauf im Kopf durchzuspielen.
• Registrierung mit einer E-Mail wiederholen, die es schon gibt.
• Browser schließen, neu öffnen, Adresse aufrufen: Ist die Sitzung noch da, und soll sie das sein?
• Abmelden und danach die Zurück-Taste drücken. Geschützte Inhalte dürfen nicht aus dem Zwischenspeicher zurückkommen.

Jeder gefundene Punkt wird eine Änderung, und mehrere Punkte passen in eine einzige Nachricht. Das ist der Grund, warum sich das Testen lohnt, bevor Sie nachbessern: gebündelt kostet es 3 Credits statt vier Mal 3.

Vor der Auslieferung startet Zugo jeden Build in einer Sandbox. Ein Build, der nicht geladen hat, wird nicht ausgeliefert. Diese Prüfung beantwortet genau eine Frage, nämlich ob das Projekt startet. Sie ersetzt Ihren Test mit zwei Konten nicht.

Wann reicht ein Builder für Benutzerkonten nicht mehr?

Wenn die Regeln komplizierter sind als das Produkt. Ein Mandantenportal mit drei Rollen ist gut machbar. Ein Abrechnungssystem mit Vertretungsvollmachten, Vier-Augen-Prinzip und Revisionssicherheit ist es nicht, jedenfalls nicht als Ergebnis eines Prompts.

Zugo ersetzt bei einem komplexen Produkt kein Entwicklungsteam. Sehr spezifische Fachlogik entsteht über viele Änderungen, und ab einem gewissen Punkt ist ein Mensch, der die Datenbank versteht, schlicht schneller. Der Übergang ist trotzdem kein Bruch: Der Quellcode lässt sich nach GitHub exportieren und der Betrieb auf ein eigenes Vercel-Konto legen. Was ein Portal mit Konten und Datenbank sonst noch braucht, steht in App ohne Programmieren erstellen.

Womit fange ich an?

Mit dem kleinsten Portal, das schon einen Nutzen hat. Eine geschützte Seite, zwei Rollen, echte Daten. Eine einfache Sache steht in etwa einer Minute, eine mehrseitige Plattform in einigen Minuten, und danach ist jede Korrektur ein Satz.

Auf zugo.dev starten Sie mit 5 Credits und einer der 25 Vorlagen, von denen fünf Spiele sind. Veröffentlichen Sie das Ergebnis auf eine Adresse wie ihr-portal.zugo.run, legen Sie zwei Testkonten an und laufen Sie die Prüfliste ab. Erst danach lohnt sich die eigene Domain.

Ein Login ist kein Meilenstein. Er ist die Tür, hinter der Ihr eigentliches Produkt anfängt.