Internes Dashboard bauen mit n8n, Supabase und Claude

Wer ein internes Dashboard bauen will, kennt die Lage meist schon. Der echte Stand der Firma liegt in fünf Systemen, und für jede Frage öffnet man ein anderes. Seit Herbst 2026 nutzen wir dafür Ops. Das ist ein eigenes Cockpit, das Buchhaltung, CRM, laufende Workflows, LinkedIn und Kalender in einer Ansicht zeigt. Gebaut ist es mit n8n, Supabase und einer kleinen Web-App, entwickelt mit Claude Code.

Der Bericht richtet sich an Geschäftsführer im Mittelstand, die überlegen, so etwas selbst zu bauen. Code zeigen wir keinen. Wir beschreiben die Entscheidungen, die Reihenfolge und die Fehler, die wir erst mit echten Daten gesehen haben. Eine Kurzfassung des Projekts finden Sie in unserer Case Study zu Ops.

Ops bündelt die Systeme, in denen bei uns der echte Stand liegt. Das sind diese fünf:

• sevDesk für die Buchhaltung, also Rechnungen und offene Posten.
• HubSpot als CRM mit Kontakten und Deals.
• n8n mit den Workflows, die bei uns laufen, und der Frage, ob sie sauber durchlaufen.
• LinkedIn mit Beiträgen und Entwürfen.
• Der Kalender mit den Terminen der Woche.

Die wichtigste Regel haben wir vor der ersten Zeile festgelegt. Ops ist ein Lese-Abbild, geändert wird nur in den Quellsystemen. Eine Rechnung korrigieren wir in sevDesk, einen Deal pflegen wir in HubSpot. Beim nächsten Abruf holt Ops den neuen Stand.

Ausnahmen gibt es für Daten, die es sonst nirgends gibt. Planwerte sind so ein Fall. Kein Buchhaltungsprogramm kennt unser Ziel für das nächste Quartal, also pflegen wir es direkt in Ops.

Die Regel erspart uns eine Frage, an der viele Dashboards hängen bleiben. Wenn zwei Systeme verschiedene Zahlen zeigen, gilt bei uns immer die Quelle. Darüber muss niemand diskutieren.

1. 1

   Abholen mit n8n

   n8n holt die Rohdaten mehrmals am Tag nach Zeitplan und zusätzlich auf Knopfdruck. Für den Zeitplan reicht der eingebaute Schedule Trigger. Der Workflow reicht die Rohdaten an eine Funktion in der Datenbank weiter und tut sonst wenig.

2. 2

   Rechnen in Postgres

   Die Datenbank ist Postgres bei Supabase. Dort liegt die ganze Logik in SQL. Dazu gehört, was als offen zählt, welcher Betrag zu welchem Monat gehört und welche Zahl auf welcher Karte steht.

3. 3

   Anzeigen mit Next.js

   Eine Next.js-App auf Vercel zeigt alles an. Sie liest fertige Ergebnisse aus der Datenbank und rechnet selbst kaum etwas.

4. 4

   Zugang und Rechte

   Anmelden können sich nur freigeschaltete Adressen. Welche Seite jemand sehen darf, prüft die Datenbank selbst. Supabase nutzt dafür Row Level Security, also Zugriffsregeln, die direkt in Postgres laufen. Auch ein Fehler in der App gibt so keine Daten frei, die jemand nicht sehen soll.

Dass die Logik in SQL liegt, war die Entscheidung mit der größten Wirkung. Ein Workflow, der nur Daten holt, bleibt kurz und leicht zu lesen. Geschäftsregeln in der Datenbank lassen sich an einer Stelle prüfen und mit Tests absichern.

Für Sie als Geschäftsführer heißt das vor allem eins. Wenn eine Zahl im Cockpit falsch aussieht, gibt es genau einen Ort, an dem man nachsehen muss. Das spart bei jeder Rückfrage Zeit.

Ein Cockpit für alles auf einmal wäre ein langes Projekt geworden, und am Ende hätte vermutlich keiner es täglich geöffnet. Wir sind deshalb Bereich für Bereich vorgegangen, in dieser Reihenfolge:

1. 1

   1. Finanzen

   Die erste Frage galt Rechnungen und offenen Posten. Die stellen wir jeden Tag, und die Antwort lag bisher verteilt in sevDesk.

2. 2

   2. Markt

   Als zweiter Bereich kam Markt dazu. Wir haben ihn erst angefangen, als die Finanzseite täglich genutzt wurde.

3. 3

   3. Sales und Content

   Zuletzt kamen der Vertrieb aus HubSpot und der Content mit LinkedIn und Blog.

Die Regel dahinter ist einfach. Ein neuer Bereich kommt erst, wenn der vorige täglich genutzt wird. Bleibt eine Seite ungeöffnet, fehlt ihr meist eine Antwort, die jemand wirklich braucht. Das sieht man früh und kann es beheben, bevor der nächste Bereich darauf aufbaut.

Im Alltag schreibt Claude Entwürfe für LinkedIn und für diesen Blog. Ops speichert die Entwürfe an einer Stelle, an der wir sie lesen und bearbeiten. Live geht nichts ohne Freigabe durch einen Menschen. Auch dieser Artikel ist so entstanden.

Gebaut haben wir Ops mit Claude Code. Damit das Ergebnis verlässlich bleibt, gelten beim Bauen feste Regeln:

• Jede Änderung kommt als Pull Request und wird gelesen, bevor sie übernommen wird.
• Bei jedem Pull Request laufen automatische Prüfungen mit.
• Für alle Berechnungen gibt es Tests. Ändert sich eine Zahl unbeabsichtigt, fällt das am Test auf, bevor jemand mit ihr arbeitet.

Der Aufwand für diese Regeln ist klein. Dafür können wir jede Änderung auch Wochen später nachvollziehen und wissen, wer sie freigegeben hat. Gerade bei Finanzzahlen ist uns das wichtiger als Tempo.

1. 1

   Finanzen

   Laut sevDesk-Hilfe erzeugt ein Storno eine Stornorechnung mit Bezug auf das Original. In den Daten, die bei uns ankamen, stand die stornierte Rechnung trotzdem weiter auf offen. Erst die Stornorechnung verriet, dass sie erledigt war. Seitdem ordnen wir in SQL jede Stornorechnung ihrem Original zu, bevor wir offene Posten zählen.

2. 2

   Markt

   Schnittstellen liefern Daten seitenweise. Bei sevDesk sind seit dem 30. Mai 2025 höchstens 1.000 Einträge je Abruf erlaubt. Bricht ein Import nach der dritten Seite ab und räumt danach auf, verschwinden echte Datensätze aus dem Cockpit. Bei uns darf ein Import deshalb nur löschen, wenn sicher ist, dass er alle Seiten geholt hat.

3. 3

   Sales und Content

   Die kleinste Rechenstufe bei Supabase war für uns zu klein und machte jede Abfrage langsam. Die nächste Stufe heißt Small und kostet laut Supabase rund 15 Dollar im Monat.

Viele Unternehmen haben bereits Workflows, die Daten zwischen Systemen bewegen. Ein Cockpit setzt auf diesen Workflows auf. Sie holen ohnehin Daten ab, und jetzt landen diese zusätzlich an einer Stelle, an der man sie lesen kann. Der größte Teil der Arbeit steckt dann in klaren Regeln für die Daten und weniger in der Oberfläche.

Diese Punkte sollten Sie klären, bevor Sie anfangen:

1. 1

   Welche Frage zuerst

   Wählen Sie eine Frage, die täglich gestellt wird und eine eindeutige Antwort hat. Offene Posten oder der Stand der Deals sind gute Kandidaten.

2. 2

   Wo die Quelle liegt

   Legen Sie für jede Zahl fest, welches System gilt. Was nirgends liegt, etwa Planwerte, darf im Cockpit gepflegt werden.

3. 3

   Wer was sieht

   Legen Sie die Rechte je Seite früh fest, gerade bei Finanzdaten. Lassen Sie sie in der Datenbank prüfen, damit ein Fehler in der Oberfläche keine Daten freigibt.

4. 4

   Wer es pflegt

   Schnittstellen ändern sich, wie sevDesk 2025 mit den neuen Seitengrenzen gezeigt hat. Jemand muss Importe und Tests im Blick behalten, auch nach dem Start.

Wenn Sie intern Leute mit SQL und etwas Erfahrung in Webentwicklung haben, können Sie so etwas mit den genannten Werkzeugen selbst bauen. Wenn Sie zuerst wissen wollen, welche Abläufe sich bei Ihnen überhaupt lohnen, ist ein KI-Audit ein ruhiger Einstieg.