Einleitung

Die meisten Automatisierungen laufen im Verborgenen. Sie brauchen keine schönen Oberflächen - wichtig ist nur, dass sie robust und zuverlässig ihre Arbeit erledigen. Zum Beispiel: Ein Dokumenten-Bot, der jede Rechnung automatisch klassifiziert und im richtigen Ordner ablegt.
Der Mensch interagiert mit diesem Bot nur passiv und vertraut darauf, dass alles läuft.
Ein einfaches Monitoringsystem reicht, das im Fehlerfall eine Meldung absetzt.

Doch wenn der Bot ohnehin durch alle Daten läuft, warum nicht auch gleich Kennzahlen sammeln? Welche Summen wurden bestellt, wie entwickeln sich Umsätze, welche Artikel werden am häufigsten reklamiert?
Anstatt diese Daten in einer wöchentlichen Mail zu versenden, wäre es sinnvoller, sie in Echtzeit zur Verfügung zu haben - wie ein Armaturenbrett im Auto, nur für die gesamte Abteilung oder Firma.
Mit anderen Worten:
Ein Dashboard

Was ist preppr?

‍

Für mein Experiment habe ich die Datenbasis von preppr genutzt - einer Web-App, die ich als Showcase-Projekt entwickelt habe.
preppr erstellt auf Knopfdruck komplette Essenspläne für eine Woche. Die Nutzer hinterlegen nur ihre Vorlieben und Einschränkungen (z.B. Allergien, Lebensmittel die man nicht mag, Aktivitätslevel). Daraus generiert die App automatisch Rezepte, eine Einkaufsliste und passende Vorbereitungsschritte.
Die Idee entstand, weil wir in der neuen Lebensrealität mit unserem “Agent des Chaos” (mein Sohn ist mittlerweile 16 Monate alt) - wieder mehr Struktur finden, Zeit sparen und gleichzeitig gesund und altersadäquat kochen wollten.

Gleichzeitig ist preppr ein idealer Agentur-Showcase: Nahezu alle Daten werden KI-gestützt generiert - ein perfektes Beispiel für praktische Automatisierung im Alltag.

Warum ein Dashboard? + Datenbasis

Ohne Dashboard operiere ich als App-Entwickler blind:
Ich weiß nicht, wie viele Nutzer die App tatsächlich hat, ob diese aktiv bleiben oder nur kurz hineinschauen und dann wieder verschwinden.
Auch der Einfluss von neuen Features oder Marketing-Aktionen bleibt unsichtbar, solange ich keine Daten im Blick habe.

Ein Dashboard löst genau dieses Problem: Es macht Fortschritt sichtbar.
Damit der messbar wird, greife ich auf die Kern-Entities der App zu:

• Users → zeigen, wie viele Menschen sich registrieren und ob ihre Zahl wächst
• Meal Plans → machen sichtbar, wie aktiv die App tatsächlich genutzt wird
• Rezepte → spiegeln den Umfang der Bibliothek und den wahrgenommenen Wert der App wider
• gekaufte Artikel → geben Aufschluss, ob Nutzer die App beim Einkauf verwenden (aktives Abhaken)

Diese vier Tabellen sind ohnehin Teil von preppr - im Dashboard aggregiere ich ihre Werte und stelle sie als KPIs und Zeitreihen dar.

Tech-Stack-Wahl

Da das Dashboard direkt in die preppr-App integriert wird, übernimmt es den bestehenden Technologie-Stack. Ziel war es, so schnell wie möglich ein funktionierendes MVP zu haben - ohne jedes UI-Element von Grund auf neu zu entwickeln.

Die wichtigsten Bausteine:

• Next.js - das populärste React-Framework mit Server-Side-Rendering und API-Routen. Perfekt, um Frontend und Backend in einem Projekt zu kombinieren
• Tailwind CSS - schnelles Layout und Styling mit Klassen im Markup statt eigenen Stylesheets
• shadcn/ui - modulare Komponentenbibliothek auf Tailwind-Basis. Spart Zeit bei wiederkehrenden UI-Elementen wie Buttons, Modals oder Tabellen
• TailAdmin - ein Admin-Template, das Sidebar, Card-Layouts und Chart-Komponenten bereits mitbringt. So konnte ich mich direkt auf die Datenverarbeitung und Logik konzentrieren

Der Stack bringt gleich mehrere Vorteile mit:

• Schneller Einstieg - sofort einsatzbereit, ohne Boilerplate selbst zu bauen
• Modularität - jedes Teil ist austauschbar, falls sich die Anforderungen ändern
• Community - die große Nutzerbasis bedeutet viele Tutorials, fertige Erweiterungen und langfristige Wartbarkeit

Aus all diesen Gründen habe ich auch vor, genau diesen Stack für Kundenprojekte zu nutzen.

Backend

Für ein Dashboard reicht es nicht, nur den aktuellen Zustand der Datenbank abzufragen. Interessant wird es erst, wenn ich die Entwicklungen über die Zeit sichtbar mache - also Wachstum und Trends.

Die Rohdaten kommen direkt aus den preppr-Tabellen (users, meal-plans, recipes, shopping_list_items). Um daraus Kennzahlen zu machen, gehe ich zweistufig vor:

1. Tagesaktuelle Werte speichern

• Eine zusätzliche Tabelle daily_stats hält pro Tag die aggregierten Summen fest: Anzahl User, Meal Plans, Rezepte und abgehakte Shopping-Items
• Zusätzlich speichere ich auch gleich die Differenzen zum Vortag ab (absolut und in Prozent). So muss das Frontend später nichts nachrechnen

2. Automatische Aktualisierung

• Ein eigener API-Endpoint (/api/cron/daily-stats) übernimmt das Aufzeichnen der neuen Werte
• Ein Cron-Job auf dem Server (in meinem Fall über Dokploy konfiguriert) ruft diesen Endpoint täglich um 02:00 Uhr auf
• Dadurch entsteht automatisch eine History, ohne dass ich manuell eingreifen muss

3. Zugriff durch das Frontend

• Über einen weiteren Endpoint (/api/stats) können aktuelle und historische Werte abgefragt werden
• Das Frontend lädt beim Aufruf der Dashboard-Seite genau diese Daten und gibt sie an die Komponenten weiter

Mit diesem Setup habe ich eine robuste Grundlage geschaffen: Die Daten sind historisiert, regelmäßig aktualisiert und für das Frontend optimiert verfügbar. Das macht den nächsten Schritt - die Visualisierung im UI - deutlich einfacher.

UI / UX

TailAdmin liefert bereits fertige Komponenten für KPI-Cards (z.B. ECommerceMetrics) und Diagramme. Auf den ersten Blick sieht das nach einem großen Zeitgewinn aus - Layout und Design sind schon da. Doch schnell fiel auf: Die Werte waren fix in den Code eingetragen.
Für eine Demo reicht das aus (wenn auch irreführend). Sobald aber echte Daten eingebunden werden sollen, fehlt die Funktionalität.

Um die Komponenten produktiv nutzbar zu machen, habe ich sie modularisiert. Der erste Schritt war, Properties einzuführen - zum Beispiel title, value und growth. Dadurch lassen sich die gleichen Komponenten mehrfach verwenden - mit echten Werten:

<ECommerceMetric_generic
 title="Users"
 value={stats.total_users}
 growth={stats.users_growth_percent}
/>


Als Nächstes musste die API angebunden werden. Beim Laden der Dashboard-Seite wird ein Call an /api/stats ausgeführt. Der liefert, wie oben beschrieben, die aggregierten Daten zurück, die anschließend an die modularisierten Komponenten weitergereicht werden.

‍

Das Ergebnis: Ein dynamisches Dashboard mit aktuellen Zahlen.

Lessons Learned

Das Projekt war im Kern simpel - ein paar Kennzahlen aus der Datenbank aggregieren und hübsch darstellen. Trotzdem habe ich unterwegs einige wertvolle Dinge gelernt:

Backend

• Scheduled Calls mit Dokploy: Cron-Jobs lassen sich direkt im UI anlegen und triggern meinen API-Endpoint zuverlässig jeden Tag um 02:00 Uhr. Kein externer Scheduler notwendig.
• Header-Authentifizierung: Um den Cron-Endpoint abzusichern, musste ich eigene Checks einbauen. Interessant: Docker verwendet intern die IPv6 ::ffff:127.0.0.1 für localhost.
• TypeScript-Quirks: Bei der Berechnung von Growth-Werten musste ich wieder einmal mit null-Types kämpfen. Am Ende war es eine simple Lösung mit 0 || 1 als Fallbnack, aber genau diese Kleinigkeiten kosten immer ein bisschen Zeit und Nerven.

Frontend

• TailAdmin-Erkenntnis: Das Template sieht auf den ersten Blick voll funktionsfähig aus, entpuppt sich aber schnell als “Potemkinsches Dorf”. Viele Werte waren hardcoded, echte Datenanbindung nicht vorgesehen. Für eine kostenlose Basis bin ich dankbar - aber ohne eigene Anpassungen wäre es nur eine Demo geblieben.
• apexcharts: Auf der positiven Seite habe ich ein neues Lieblingsprojekt entdeckt. Apexcharts ist leichtgewichtig, flexibel und hat genau die richtige Balance zwischen Features und Einfachheit. Ideal für Dashboards.

‍

Fazit und Ausblick

Mit einer zusätzlichen Tabelle, einem Cron-Job und ein wenig Komponenten-Feinschliff ist aus einer Idee schnell ein funktionierendes Dashboard geworden.
Es zeigt auf einen Blick die wichtigsten Kennzahlen von preppr - User, Meal Plans, Rezepte und abgehakte Einkaufslisten - und macht damit schnell sichtbar wie die App genutzt wird und sich entwickelt.

Für mich als Entwickler war es zwar ein kleines aber dennoch spannendes Projekt:
Ich habe mehr über Dokploy-Schedules, abgesicherte API-Endpoints und die Datenaufbereitung gelernt.
Auf der Frontend-Seite war TailAdmin eine nützliche Zeitersparnis, auch wenn viel Nacharbeit nötig war. Und mit Apexcharts habe ich ein neues Lieblingswerkzeug gefunden, um Daten visuell ansprechend darzustellen.

Schau doch gerne unter https://preppr.aints.at/metrics vorbei, um dir selbst ein Bild davon zu machen.

Im nächsten Teil dieser Serie geht es tiefer ins Backend: Wie ich mit n8n und Supabase Daten KI-unterstützt verarbeite und warum genau diese Kombination für viele meiner Projekte ideal ist.

‍