ContentFlow

Overview

ContentFlow is a personal-but-production-grade content planning system designed to handle the realities of multi-channel publishing. A single piece of work (an article, a video, a podcast episode) fans out across many destinations like Substack, Medium, LinkedIn, YouTube, and Acast, and is followed by a tail of promotional posts across social platforms. ContentFlow models that lifecycle directly so the planning, scheduling, and post-mortem live in one place rather than scattered across spreadsheets, calendar invites, and a Notion page nobody reads.

Architecture

• Backend: Django 6 with Django REST Framework, drf-spectacular for OpenAPI, and django-filter for query composition.
• Database: PostgreSQL via psycopg 3.
• Admin UX: django-unfold for a modernized admin surface. The admin is the primary operator UI here, not an afterthought.
• Static + serving: WhiteNoise for static assets and Gunicorn for app serving, all containerized.
• Deploy: A single VPS behind an existing Traefik reverse proxy. Images build locally and push to a private registry; the production compose file pulls and runs migrations from the entrypoint. DNS at cf.five59.com.
• Calendar export: First-class iCal output via icalendar, so any planning view can be subscribed to from a real calendar app.

ContentFlow MCP

A companion contentflow-mcp package exposes the API to AI assistants via the Model Context Protocol, so a conversational agent can read the publishing pipeline, propose scheduling, and write back updates without screen-scraping the admin.

This is intentionally a small, separate package: the core ContentFlow app stays AI-agnostic, and the MCP layer can evolve (or be replaced) without touching the data model.

Why a personal project that looks like production

The goal isn't "the simplest thing that works for me." It's "a sharply scoped tool that demonstrates the deploy story I'd recommend to a client." Traefik routing, container registry workflow, migration-on-entrypoint, structured admin UX, and an MCP integration layer are all things that real teams want; building them on a project I personally use means they've been pressure-tested before they're pitched.