TL;DR
Ich wollte meine bestehenden Dashboards sinnvoll erweitern, ohne noch ein Dashboard zu bauen. Deshalb habe ich ein Server-Tool entwickelt, das die wichtigsten Kennzahlen der letzten sieben Tage automatisch als PDF-Report zusammenstellt und per E‑Mail verschickt. Die Daten kommen aus derselben Datenbank wie das Dashboard, das Layout ist minimalistisch und an die Dashboard-Optik angelehnt, der Versand läuft über SMTP. Die Entwicklung war überraschend reibungslos – mit gezielten Anpassungen am Layout. Wichtigstes Learning: Nicht jede Aufgabe braucht ein LLM; für strukturierte Reports reichen oft ein gutes Template und saubere Aggregation. ✨
Kontext & Ziel
Der Ausgangspunkt war sehr pragmatisch: ich wollte weiter an Dashboards arbeiten, ohne ein weiteres Dashboard zu bauen. Also habe ich mir überlegt, was könnte eine sinnvolle Ergänzung sein?
Dashboards sind großartig für Interaktivität und Ad‑hoc‑Analysen, aber im Alltag schauen viele Entscheider nicht täglich hinein. Ich wollte eine Möglichkeit schaffen, die Essenz des Dashboards regelmäßig, verlässlich und automatisch in die Inbox zu liefern. Der Scope war bewusst minimalistisch gesteckt: Daten aus der bestehenden Datenbank ziehen, die Woche aggregiert zusammenfassen, in ein klar strukturiertes PDF geben und anschließend an definierte Empfänger verschicken. Kein zusätzliches UI, keine Konfigurationsoverkill, keine generierten Texte – sondern ein solides Werkzeug, das jede Woche denselben Mehrwert liefert. Parallel sollte die Lösung sich mit sehr wenig Aufwand in einen Server‑Scheduler integrieren lassen, damit der Versand automatisch passiert und niemand daran denken muss.
Meine Anforderungen
Ich möchte einen wöchentlichen PDF‑Report, der aus dem Dashboard aus Woche 15 die wichtigsten Daten der letzten sieben Tage zusammenfasst
Der Report soll aus derselben Datenbasis wie das bestehende Dashboard gespeist werden, damit Zahlen konsistent bleiben
Der Versand soll direkt aus dem Tool heraus per E‑Mail möglich sein, inklusive mehrerer Empfänger
Das Layout soll übersichtlich und wiedererkennbar sein
Die Lösung soll als Server‑Skript laufen und sich unkompliziert planen lassen (z. B. wöchentlich)
Mein AI-Workflow
Die Struktur des Projekts habe ich dieses Mal direkt mit Claude Code geplant und dabei Funktionen, Datenfluss und sinnvolle Module diskutiert. Diese Schritte habe ich bisher vorab mit Claude getätigt, aber Claude Code ist das offensichtlich ein ebenso guter Partner.
Für die Ideenfindung gab es zu Beginn eine kurze Brainstorming‑Runde mit ChatGPT, die u. a. den Impuls „automatische Reports aus Dashboards“ geliefert hat. ChatGPT hat mir vorgeschlagen den Report mit einem LLM erstellen zu lassen, aber als ich Claude Code mein Dashboards gezeigt habestellte sich heraus, dass man einen passenden Report auch gut ohne LLM im Hintergrund erstellen kann.
Die eigentliche Implementierung lief dann durchgehend mit Claude Code; das Bild für den Blogpost habe ich wie (fast) immer mit ChatGPT erzeugt.
Was das Tool kann
👉 Du startest ein Skript auf dem Server, wählst eine Stadt und optional ein Enddatum, und erhältst automatisch einen PDF‑Report für die letzten sieben Tage 📄
👉 Der Report fasst das Wesentliche zusammen: Wetter‑Durchschnittswerte und Spannen, Gesamtniederschlag, Regentage sowie Energie‑Indikatoren wie Solar‑ und Windpotenzial – alles konsistent aus derselben Datenbank wie das Dashboard
👉 Die Darstellung ist bewusst simpel: Titel, Metadaten (Zeitraum, Stadt, Erstellungsdatum), kompakte Statistik‑Karten und tabellarische Tagesübersichten, optisch angelehnt an die Dashboard‑Komponenten
👉 Direkt nach der Erzeugung kann der Report per SMTP automatisch an eine oder mehrere E‑Mail‑Adressen verschickt werden ✉️
👉 Die Ausführung ist so gebaut, dass sie sich mit minimalem Aufwand in einen wöchentlichen Planer integrieren lässt (z. B. Cron auf dem Server)
Stack & Tools
Backend/CLI: Python
Reporting: ReportLab für die strukturierte PDF‑Erzeugung (Kopfzeile, KPI‑Blöcke, Tabellen, Seitenumbrüche)
Daten: MariaDB/MySQL als Datenquelle des Dashboards
E‑Mail: Versand via SMTP mit klassischer Authentifizierung
Deployment: Als Server‑Skript ausgeführt; Planung über den System‑Scheduler
Herausforderungen & Learnings
Nicht alles muss mit AI laufen: Für strukturierte, wiederkehrende Wochenreports reichen oft saubere Aggregationen und ein gutes Template. Natürlich kann der Report noch mit Textbausteine ergänzt werden, aber selbst diese können oft nach Fallunterscheidungen ausgewählt werden. Nur weil etwas mit einem LLM automatisiert werden kann, MUSS man es nicht mit einem LLM automatisieren.
Wiederverwendung spart Zeit: Ich konnte bestehende Bausteine für DB‑Anbindung und SMTP‑Versand aus alten Wochenprojekten wiederverwenden und dadurch Zeit und Nerven sparen.
Feinschliff statt Fehlersuche: Die Entwicklung lief nahezu fehlerfrei. Die Arbeit steckte vor allem in Layout‑Details und der Auswahl sinnvoller Kennzahlen. 🔧
Keine Live-Demo
Keine Live‑Demo – das Tool läuft serverseitig als Skript und liefert das Ergebnis als PDF per E‑Mail aus.
Fazit
Woche 16: ✅
Das Projekt zeigt, wie viel Nutzen in einer schlichten, gut integrierten Automatisierung steckt.
Ich merke immer mehr, dass mir die Arbeit mit Daten besonders viel Spaß macht. Ebenso weiß ich, dass mir stundenlanger „Prompt Feinschliff“ bei LLM-Integration weniger Spaß macht. Ich mag deterministische Lösungen. Ich bin gespannt, ob es hier in den nächsten Wochen mit Dashboards weitergeht, oder ob es noch andere Nischen gibt, die mich so begeistern.
