MoneyPrinter
KI-Content-Fabrik für viele Plattformen
Gebaut von Rogue AI · Ein Thema rein, viele plattformgerechte Entwürfe raus · Selbst gehostet · Lokales Lab
Allein über einen konzentrierten Zeitraum im Lab gebaut; alter VPS abgeschaltet, läuft jetzt nur noch lokal.
Das Problem
Eine Idee über viele Plattformen zu veröffentlichen ist mühsam und repetitiv: dasselbe Thema muss für einen Blog umgeschrieben, in kurze Social-Posts umgeformt, in ein Videoskript verwandelt und mit Thumbnail-Ideen versehen werden — jeweils mit anderen Längen-, Ton- und Formatregeln. Das per Hand für jede Plattform zu machen ist genau die Arbeit, die die meisten überspringen, und so wird Content entweder einkanalig oder schlecht kopiert. MoneyPrinter ist eine Studie darüber, dieses Auffächern in eine einzige Anfrage zu bündeln und dabei einen Menschen in der Schleife zu halten, der freigibt, was tatsächlich rausgeht.
Was ich gebaut habe
Ein Next.js-16-/React-19-Frontend nimmt ein Thema und eine Zielmenge an Plattformen entgegen und übergibt die schwere Arbeit über eine Redis-Queue an einen Python-FastAPI-Worker. Der Worker führt plattformspezifische Pipelines aus — Text für Social und Langform, eine achtstufige Pipeline für Video plus Thumbnail-Generierung — und schreibt die fertigen Medien in ein gemeinsames Volume, das die App schreibgeschützt zurückliest. LLM-Aufrufe laufen über einen Provider-Schalter: standardmäßig ein lokales Modell, oder eine Host-Bridge zu einem Claude-Plan, sodass derselbe Code vollständig offline oder gegen ein stärkeres Modell läuft. Die Authentifizierung ist eine kleine Custom-JWT-Schicht statt eines schwergewichtigen Frameworks, da die App mandantenlos ist.
Architektur
Tech-Stack
Was zuerst gebrochen ist
- ▸
Webanfrage und Content-Generierung gehören in getrennte Prozesse. Die Next.js-App bleibt reaktionsschnell, weil die langsame Arbeit — Modellaufrufe, Videomontage, Bildrendering — in einem separaten FastAPI-Worker liegt, der aus einer Redis-Queue zieht, und nicht im HTTP-Handler.
- ▸
Eine Quellidee ist nicht ein Output. Ein einzelnes Thema in einen Blogbeitrag, ein paar Social-Varianten, ein Videoskript und Thumbnail-Prompts zu verwandeln, ist vor allem ein Adapter-Problem: jede Plattform bekommt ihre eigene Prompt-Form und ihre eigenen Längenregeln statt eines generischen Aufrufs, der überall wiederverwendet wird.
- ▸
Bei langen Jobs zählt Fortschrittssichtbarkeit mehr als reine Geschwindigkeit. Den schrittweisen Fortschritt über Redis pub/sub zu streamen, ließ eine mehrminütige Video-Pipeline wie einen Vorgang wirken, dem man zusehen kann, statt wie einen Spinner, dem man misstraut.
Ergebnis
Eine funktionierende End-to-End-Demo: ein Thema einreichen, plattformspezifischen Jobs mit Live-Fortschritt auf dem Worker zusehen und Entwürfe zurückbekommen, die für jeden Kanal geformt sind, plus generierte Thumbnails — alles selbst gehostet, mit einem menschlichen Freigabeschritt, bevor irgendetwas als final gilt. Es steht als Musterbeweis für den Teil, der in echten Systemen zählt: die Web-App reaktionsschnell halten, indem man die Generierung in einen queue-gespeisten Worker schiebt, und Multi-Plattform-Output als Adapter-Problem behandeln statt als Prompt zum Kopieren.
Ehrliche Grenzen
Das ist ein Demo- und Musterbeweis, kein gelaunchtes Produkt. Es gibt keine echten Nutzer, keine veröffentlichten Volumenkennzahlen und nichts wird automatisch auf echte Social-Accounts gepostet — es erzeugt Entwürfe zur Durchsicht. Es ist ein selbst gehosteter Einzelautor-Build, der in einem lokalen Lab läuft (der alte VPS wurde abgeschaltet). Der Zweck ist, eine saubere Trennung zwischen Web-App und schwerem Generierungs-Worker zu zeigen, und wie ein Thema in plattformgerechte Inhalte aufgefächert wird — nicht, ein fertiges SaaS zu behaupten.