SaaS-Dashboard ohne Code bauen: Login, Daten, Grenzen

SaaS-Dashboard ohne Code bauen: Login, Daten, Grenzen

Ein SaaS-Dashboard entsteht in Zugo aus einer Beschreibung der Rollen, Kennzahlen und Tabellen. Der Builder erzeugt die Oberfläche, Supabase liefert Datenbank und Login, Stripe den Abo-Status. Bis zur inneren Ansicht mit echten Daten führt der Weg über mehrere Änderungen, nicht über einen einzigen Prompt.

Das ist keine Einschränkung, sondern die normale Reihenfolge. Ein Dashboard ist kein Layout mit Diagrammen, sondern eine Anwendung mit Zuständen: angemeldet, nicht angemeldet, ohne Daten, mit zu vielen Daten, Abo abgelaufen.

Was ist mit einem SaaS-Dashboard überhaupt gemeint?

Der Begriff steht für zwei sehr verschiedene Dinge, und die Verwechslung kostet die meiste Zeit. Gemeint sein kann der interne Bereich, in dem Ihre Kunden nach dem Login arbeiten, oder die Auswertungsansicht, in der Sie selbst Umsatz und Nutzung verfolgen.

Der Kundenbereich ist das eigentliche Produkt. Er braucht Konten, Berechtigungen, saubere Trennung der Daten je Kunde und einen Zustand für alles, was schiefgehen kann. Er wächst über Wochen, nicht über einen Nachmittag, auch wenn die erste Version schnell steht.

Die interne Auswertung ist deutlich einfacher. Wenige Nutzer, bekannte Fragen, keine öffentliche Anmeldung. Wer nur wissen will, wie viele Konten aktiv sind und wie sich der Umsatz entwickelt, ist damit oft an einem Tag fertig. Klären Sie also zuerst, welches der beiden Dinge Sie bauen.

Welche Bausteine braucht ein Dashboard mindestens?

Die Reihenfolge in dieser Tabelle ist zugleich die Baureihenfolge. Ohne Anmeldung gibt es keinen Kunden, ohne Kunden keine Datentrennung, und ohne Datentrennung ist jede Kennzahl auf der Übersicht bedeutungslos, weil sie über alle Konten hinweg zählt.

Was fast immer vergessen wird, sind die leeren Zustände. Ein neues Konto sieht am ersten Tag eine leere Tabelle, und genau dieser Bildschirm entscheidet, ob jemand bleibt. Schreiben Sie in den Prompt, was dort stehen soll und welche Schaltfläche dort sichtbar ist.

Wie beschreibt man ein Dashboard im Prompt?

Beschreiben Sie Rollen, Ansichten und Datenfelder, nicht das Aussehen. Ein Prompt, der ein tragfähiges Grundgerüst erzeugt, klingt so:

Interner Bereich für ein Werkzeug zur Rechnungsverwaltung. Anmeldung per Mailadresse. Zwei Rollen: Inhaber und Mitarbeiter, Mitarbeiter sehen keine Umsätze. Übersichtsseite mit vier Kennzahlen: offene Rechnungen, überfällige Rechnungen, Umsatz laufender Monat, neue Kunden im Monat. Seite mit einer Liste aller Rechnungen mit Suche, Filter nach Status und Blättern. Detailseite je Rechnung mit Bearbeiten und Statuswechsel. Seite Einstellungen mit Profil, Team und Abmelden. Leerer Zustand mit Hinweis und Schaltfläche „Erste Rechnung anlegen“. Sachliche Gestaltung, helle Oberfläche, Tabellen gut lesbar.

Nennen Sie die Felder je Tabelle ruhig einzeln. Ein Datenmodell, das im ersten Durchgang stimmt, spart mehrere Änderungen, denn nachträglich eine Spalte einzuziehen ist teurer als sie gleich mitzunennen.

Verzichten Sie dagegen auf Angaben zu Farben, Schriften und Abständen. Diese Dinge sind eine spätere Änderung von wenigen Minuten und lenken den ersten Build von der Struktur ab.

Wie entstehen Login und Rollen?

Die Anmeldung übernimmt Supabase, und das ist der Punkt, an dem Sie am wenigsten improvisieren sollten. Konten, Passwörter und Sitzungen sind gelöste Probleme, und eine eigene Lösung ist an dieser Stelle immer die schlechtere. Was dabei entsteht, beschreibt Kann KI Login und Benutzerkonten bauen.

Rollen sind mehr als eine Spalte in der Nutzertabelle. Entscheidend ist, dass die Datenbank selbst durchsetzt, wer welche Zeile sehen darf, und nicht nur die Oberfläche einen Menüpunkt ausblendet. Ein versteckter Knopf ist keine Berechtigung, sondern eine optische Täuschung.

Formulieren Sie deshalb im Prompt ausdrücklich, welche Rolle welche Daten sieht, und prüfen Sie es danach mit einem zweiten Testkonto. Melden Sie sich als Mitarbeiter an und versuchen Sie, eine Umsatzansicht direkt aufzurufen. Was dabei erscheint, ist die ehrliche Antwort. Die Datenseite dazu erklärt KI-App-Builder mit Supabase.

Welche Kennzahlen gehören auf die Startansicht?

Vier bis sechs, nicht mehr. Jede weitere Zahl verringert die Aufmerksamkeit für alle anderen, und ein Dashboard mit vierzehn Kacheln wird nach zwei Wochen nur noch überflogen. Wählen Sie die Zahlen, auf die Sie tatsächlich reagieren würden.

Jede Kennzahl braucht einen Zeitraum und einen Vergleich. „412 aktive Konten“ sagt wenig, „412 aktive Konten, im Vormonat 389“ sagt etwas. Ohne Vergleich ist eine Zahl nur eine Zahl, und die Interpretation überlassen Sie dem Betrachter.

Achten Sie außerdem auf die Definition. Was „aktiv“ bedeutet, muss festgelegt und irgendwo nachlesbar sein, sonst streiten zwei Personen im Team über eine Zahl, die schlicht unterschiedlich gemeint war. Schreiben Sie die Definition in den Prompt, dann steht sie auch in der Oberfläche.

Wie kommt der Abo-Status ins Dashboard?

Über Stripe. Dort liegen Tarif, Zahlungsstatus und Kündigung, und das Dashboard liest diesen Zustand aus, statt ihn selbst zu verwalten. Alles andere führt früher oder später zu einem Konto, das laut Ihrer Datenbank bezahlt hat und laut Zahlungsanbieter nicht.

Wichtig sind drei Fälle, die im Prompt vorkommen sollten: Testzeitraum läuft, Abo aktiv, Zahlung fehlgeschlagen. Der dritte ist der interessante, denn er entscheidet, ob jemand ausgesperrt wird oder eine freundliche Erinnerung bekommt. Legen Sie das bewusst fest.

Wenn Ihr Tarif Mengen begrenzt, etwa eine Zahl von Projekten oder Nutzern, gehört die Anzeige des verbrauchten Kontingents ins Dashboard. Ein Limit, das erst beim Anlegen sichtbar wird, wirkt wie ein Fehler, obwohl es die Regel ist.

In welcher Reihenfolge baut man ein Dashboard?

Eine einfache Seite steht in etwa einer Minute, eine mehrseitige Plattform braucht einige Minuten. Vor der Auslieferung läuft jeder Build in einer Sandbox, und was dort nicht öffnet, sehen Sie gar nicht erst. Ein vollständiges Dashboard entsteht trotzdem nicht in einem Durchgang, sondern in fünf bis fünfzehn Änderungen.

Bauen Sie in dieser Reihenfolge und widerstehen Sie der Versuchung, die Gestaltung vorzuziehen. Solange Rechte und Datenmodell nicht stehen, ist jede Politur an der Oberfläche Arbeit, die Sie danach noch einmal machen.

Was kostet ein Dashboard im Builder?

Die Tarife: Free enthält 5 Credits, Pro kostet 25 $ im Monat und enthält 200 Credits, Business kostet 99 $ im Monat und enthält 800. Zweihundert Credits entsprechen etwa 16 mehrseitigen Plattformen oder 33 Builds oder 66 Änderungen.

Ein Dashboard verbraucht mehr als eine Website, weil es aus Änderungen besteht. Rechnen Sie für eine erste tragfähige Fassung mit einem mehrseitigen Aufbau und etwa zehn Änderungen. Das bleibt im Pro-Tarif und liegt unter einem Tagessatz für Entwicklungsarbeit. Ein verwandtes Beispiel mit Datenhaltung ist CRM ohne Programmieren erstellen.

Wo hört der Builder beim SaaS-Dashboard auf?

Bei allem, was tief in der Fachlogik sitzt. Komplexe Preisberechnungen, Abrechnung nach Verbrauch, Mandantenmodelle mit verschachtelten Organisationen, Schnittstellen zu bestehenden Systemen: Das entsteht nicht aus einem Prompt, sondern über viele Änderungen, und ab einer gewissen Größe ersetzt der Builder kein Entwicklungsteam.

Auch beim Datenschutz bleibt Verantwortung bei Ihnen. Ein Dashboard mit Kundendaten braucht ein Verzeichnis der Verarbeitungstätigkeiten, einen Auftragsverarbeitungsvertrag mit Ihren Dienstleistern, eine Löschregel und eine Antwort auf Auskunftsersuchen. Der Builder erzeugt Oberfläche und Datenbank, nicht Ihre Rechtsgrundlage.

Der Quellcode lässt sich über GitHub exportieren und über Vercel im eigenen Konto betreiben, was den wichtigsten Einwand entkräftet: Sie bleiben nicht gefangen, wenn das Projekt größer wird als der Builder. Für den Weg von der Idee zur ersten benutzbaren Fassung ist er dagegen der schnellste Start, und ausprobieren können Sie ihn auf zugo.dev.