Angefangen hat es mit einer CSV-Datei.
Eine modulare Plattform fürs Marketing — zu zweit gebaut, aus einem Reporting-Prototyp gewachsen, bis heute nicht fertig.
Die Ausgangslage
Die Zahlen lagen überall. Zusammengetragen hat sie jemand von Hand.
Wer wissen wollte, ob eine Kampagne getragen hat, musste die Zahlen aus den Anzeigenplattformen, dem Newsletter-Werkzeug, der Web-Analyse und dem Shop einzeln zusammensuchen. Das kostete jedes Mal Stunden — und weil es so lange dauerte, passierte es selten. Entschieden wurde dann aus dem Bauch, obwohl die Daten vorhanden waren.
Der erste Anlauf war klein und entsprechend unbeholfen: ein Upload für CSV-Dateien mit einer eigenen Auswertungsansicht im Browser. Das hat die Zahlen an einen Ort gebracht, aber jemand musste sie weiterhin exportieren und hochladen.
Dabei zeigte sich das eigentliche Problem. Es ging nicht um ein Dashboard mehr, sondern um sehr verschiedene Aufgaben, die sich nur die Datenbasis teilen — auswerten, planen, freigeben, abrechnen. Alles davon in ein Werkzeug zu bauen, hätte ein unbedienbares Werkzeug ergeben.
Was ich beigetragen habe
Konzeption und Umsetzung, zu zweit mit einem Kollegen. Meinen Teil habe ich mit Claude Code gebaut.
- Rolle
Konzeption, Modulschnitt, Oberfläche — und Umsetzung mit Claude Code
- Im Team
gemeinsam mit einem Kollegen, von Anfang an
- Zeitraum
seit 2025, im Betrieb und weiterhin in Entwicklung
- Bausteine
Der Weg dorthin
Acht Schritte über anderthalb Jahre. Der erste war der kleinste.
-
.01
Klein anfangen
Der Anfang war ein Upload für CSV-Dateien mit einer eigenen Auswertungsansicht — eine Beta unseres ersten Entwurfs. Sie hat wenig automatisiert und trotzdem eine Frage beantwortet, die vorher offen war: Wie soll die Auswertung überhaupt aussehen, wenn Zahlen aus mehreren Quellen nebeneinanderstehen? Das erste Modul war der Reporter: alle Daten aus den Schnittstellen in einem bereinigten Dashboard. Er hat den Aufwand, je Kampagne einen Bericht zu bauen, praktisch auf null gebracht — und damit die Kosten der Plattform am Anfang selbst getragen. Gebaut wird seitdem nach Nachfrage: Was Arbeit abnimmt, kommt zuerst.
-
.02
Auf Module umstellen
Statt ein Werkzeug immer weiter aufzublähen, haben wir es in Module geschnitten, die einzeln je Projekt freigeschaltet werden: Reporter und Ordermatcher fürs Auswerten, Planer und Social Media Manager fürs Veröffentlichen, Visibility Boost fürs Engagement, Provisionsfreigabe fürs Abrechnen. Der Gedanke kam auf, als wir anfingen, mit Claude Code zu arbeiten — viele kleine, klar geschnittene Bausteine wurden damit realistisch, wo vorher ein großes Werkzeug der bequemere Weg gewesen wäre.
-
.03
Das Konzept vor den Betrieb setzen
Der Modulschnitt, die Rollen und die Projektstruktur standen früh und ziemlich vollständig. Das hat sich ausgezahlt: Die Basis war schnell belastbar genug, um damit tatsächlich zu arbeiten, statt sie nebenher noch umzubauen. An dieser Stelle wäre eine schnellere Runde teurer gewesen als eine gründliche.
-
.04
Die Quellen direkt anbinden
Statt Exporte hochzuladen, holt die Plattform die Daten selbst: Shopsysteme und ein Warenwirtschaftssystem, Meta, TikTok, Pinterest und LinkedIn, Google und Microsoft Advertising, Affiliate-Netzwerke, Newsletter-Werkzeuge, Marktplätze und die Web-Analyse. Ein Teil davon ist angebunden, ein Teil vorbereitet — der Zustand steht in der Oberfläche, damit niemand rät. Der schwierigste Anschluss war Meta: langsam, anspruchsvoll und wenig entgegenkommend. Der Rest lief zuverlässig.
-
.05
Doppelte Bestellungen bereinigen
Melden Google und Meta je eine Bestellung, kann es dieselbe sein — beide beanspruchen sie für sich. Der Ordermatcher gleicht deshalb die gemeldeten Bestellungen mit denen im Shop ab und bereinigt sie. Ohne diesen Schritt addiert man Zahlen, die sich überschneiden, und das Ergebnis sieht besser aus, als es ist. Erkannt werden sie über die Kombination aus Bestellnummer, Preis in einer Spanne und Bestellzeitpunkt. Passt alles drei, ist es dieselbe Bestellung. Über einen Zeitraum abgeglichen ergibt das einen bereinigten Datenstand — und erst damit lässt sich zeigen, was über welchen Kanal wirklich hereinkommt.
-
.06
Nichts ohne Freigabe veröffentlichen
Beiträge lassen sich im Planer über einen Kalender vorbereiten und mit KI-Unterstützung entwerfen — aber der Weg nach draußen führt immer über eine Freigabe. Bei etwas, das im Namen eines Kunden erscheint, schien uns das wichtiger als ein Schritt weniger.
-
.07
Zeigen, was der Kunde sieht
Eine Kundenansicht schaltet die Oberfläche auf genau das um, was im Kundenzugang sichtbar wäre — reine Darstellung, ohne Rechte zu verändern. Das klingt nach einer Kleinigkeit und erspart die Rückfrage, ob jemand gerade etwas sieht, das er nicht sehen sollte.
-
.08
Weiterbauen statt fertigstellen
Die Plattform ist im Einsatz und wird weiterentwickelt. Neue Module lassen sich aus der Oberfläche heraus anfordern, statt dass jemand eine Liste pflegt. Ein Abschlussdatum gibt es nicht — das ist eher der Normalfall für ein Werkzeug, das täglich benutzt wird.
Aus der Arbeit
Bilder folgen. Der Stand ist beschrieben, die Ansichten reiche ich nach.
-
Bild folgt — das Dashboard mit Handlungsbedarf, Aufgaben und Modulen · vergrößern -
Bild folgt — der Reporter, mehrere Projekte in einer Ansicht kombiniert · vergrößern -
Bild folgt — Aufschlüsselung nach Plattform und Attribution · vergrößern -
Bild folgt — der Planer mit kalenderbasierter Vorbereitung · vergrößern -
Bild folgt — Modulübersicht eines Projekts mit Freigabestand · vergrößern
Was sich geändert hat
Im Betrieb, in Entwicklung — und mit Zahlen, die hier nichts zu suchen haben.
Aus dem CSV-Upload ist eine Plattform geworden, über die mehrere Dutzend Projekte betreut werden: auswerten, planen, freigeben, abrechnen. Die Plattform enthält Kundendaten und Umsätze — beides zeige ich hier nicht, weder als Zahl noch als Kundenname. Deshalb steht in dieser Fallstudie auch keine Wirkung.
Entstanden ist das zu zweit. Das gehört an den Anfang und nicht in eine Fußnote: Ein Werkzeug dieses Umfangs hätte ich allein weder gebaut noch in Betrieb gehalten. Meine Seite waren Konzeption, Modulschnitt und Oberfläche — und die Umsetzung davon habe ich mit Claude Code gemacht.
Das gehört genauso dazugesagt. Was sich dadurch verschoben hat, ist weniger das Tempo als der Zuschnitt: Ein Modul zu bauen, statt eine Funktion an ein bestehendes Werkzeug zu hängen, war plötzlich nicht mehr die teurere Entscheidung. Der Modulansatz kam nicht zufällig zu dieser Zeit auf.
Der Ordermatcher ist der Teil, an dem ich am meisten gelernt habe. Dass zwei Plattformen dieselbe Bestellung für sich beanspruchen, ist bekannt; wie oft sich das im Alltag tatsächlich überschneidet, war mir vorher nicht klar. Ob unsere Zuordnung in jedem Fall die richtige trifft, kann ich nicht behaupten — sie ist nachvollziehbar gebaut, aber sie bleibt eine Zuordnung und kein Beweis.
- Angebundene Dienste
- 24Shops, Werbung, Social, Affiliate, Newsletter, Marktplätze, Analytics
- Module
- 14je Projekt einzeln freischaltbar, gebaut nach Nachfrage
- Gebaut von
- 2einem Kollegen und mir — meinen Teil mit Claude Code
So erreichst du mich
Fragen zu meiner Arbeit beantworte ich gern — eine Mail genügt.