MoneyPrinter

Multi-platform AI content factory

Built by Rogue AI · One topic in, many platform-shaped drafts out · Self-hosted · Local lab

Built solo over a focused stretch in the lab; old VPS retired, now runs locally only.

MoneyPrinter — Multi-platform AI content factory

The problem

Publishing one idea across many platforms is tedious and repetitive: the same topic has to be rewritten for a blog, reshaped into short social posts, turned into a video script, and given thumbnail ideas — each with different length, tone and format rules. Doing that by hand for every platform is the work most people skip, so content ends up either single-channel or copy-pasted badly. MoneyPrinter is a study in collapsing that fan-out into one request, while keeping a human in the loop to approve what actually ships.

What I built

A Next.js 16 / React 19 frontend takes a topic and a target set of platforms, then hands the heavy lifting to a Python FastAPI worker over a Redis queue. The worker runs per-platform pipelines — text for social and long-form, an eight-step pipeline for video, plus thumbnail generation — and writes finished media to a shared volume the app reads back read-only. LLM calls route through a provider switch: a local model by default, or a host bridge to a Claude plan, so the same code runs fully offline or against a stronger model. Auth is a small custom JWT layer rather than a heavyweight framework, since the app is single-tenant.

Architecture

Next.js app, FastAPI worker, split on purpose

The frontend (port 3019) never generates content itself. It validates input, enqueues a job, and renders results. All model calls, video assembly and image rendering happen in a separate Python FastAPI worker (port 8000) so a slow job can never block the web tier.

Redis as the job queue and progress bus

Jobs are pushed onto a Redis list and the worker consumes them with a blocking pop (BLPOP). Live progress — percent, current step, status — is published back over Redis pub/sub per job id, so the UI can show a multi-step pipeline advancing rather than a blank wait.

Per-platform adapters from one topic

Each target — blog, social posts, video script, thumbnails — is its own pipeline with its own prompt shape and length rules. The platform list drives which adapters run, so a single submitted topic fans out into platform-correct drafts instead of one generic blob reused everywhere.

Provider switch: local model or host bridge

An LLM_PROVIDER flag selects between a local Ollama model (the default, fully offline) and a host CLI bridge that routes to a Claude plan. The generation code is identical either way; only the transport changes — which keeps the demo runnable with no API keys.

Shared media volume, read-only on the app side

The worker writes videos, images and audio into a Docker volume that the Next.js container mounts read-only. The app serves artifacts it can see but never writes media itself — a clean producer/consumer boundary across the two containers.

Tech stack

Next.jsFastAPI workerCustom JWTDocker

What broke first

▸
Web request and content generation belong in different processes. The Next.js app stays responsive because the slow work — model calls, video assembly, image rendering — lives in a separate FastAPI worker pulled off a Redis queue, not inside the HTTP handler.
▸
One source idea is not one output. Turning a single topic into a blog post, a few social variants, a video script and thumbnail prompts is mostly an adapter problem: each platform gets its own prompt shape and length rules rather than one generic call reused everywhere.
▸
Progress visibility matters more than raw speed for long jobs. Streaming step-by-step progress over Redis pub/sub made a multi-minute video pipeline feel like a process you can watch instead of a spinner you distrust.

Outcome

A working end-to-end demo: submit one topic, watch per-platform jobs run on the worker with live progress, and get back drafts shaped for each channel plus generated thumbnails — all self-hosted, with a human approval step before anything is treated as final. It stands as a pattern proof for the part that matters in real systems: keeping the web app responsive by pushing generation into a queue-fed worker, and treating multi-platform output as an adapter problem rather than a prompt to copy-paste.

Honest limits

This is a demo and pattern proof, not a launched product. There are no real users, no published volume metrics, and nothing is auto-posted to live social accounts — it generates drafts for review. It is a self-hosted, single-author build running in a local lab (the old VPS has been retired). The point is to show a clean split between a web app and a heavy generation worker, and how one topic fans out into per-platform content — not to claim a finished SaaS.