3 platforms, one queue, zero editorial control.
That was the state of my content automation before I sat down to spec the dashboard. LinkedIn, X, and Threads each had their own generator, their own state files, their own publishing loop. Drafts got generated, passed a quality gate, and fired into the void. If the draft was mediocre or the timing was wrong, I found out after the fact.
The problem is not the automation. Automation is why I can run three platform engines without spending two hours a day managing content. The problem is that zero editorial visibility means you cannot catch the bad ones before they post.
What I wanted: see every draft before it goes out. Edit inline if needed. Post immediately or schedule for the next slot. Compose something manually when I have a specific take to push. Keep the comment automation untouched because that runs high frequency, low stakes, and babysitting individual replies defeats the point.
The spec came out to three core flows.
Review queue. Every pregenerated draft surfaces here with full context: platform, topic, generation timestamp, quality score. One click to edit inline, one to approve for the next slot, one to post immediately. The goal is a 30 second review per draft, not a full editing session.
Manual compose. Sometimes I know exactly what I want to say. A text area, platform selector, and post button. No generation, no queue, just publish. This is the escape hatch for when something is happening in real time and the pregenerated queue is irrelevant.
Schedule view. A simple calendar showing what is queued for which slot across all three platforms. The generator already handles slot logic and quiet hours. The dashboard just needs to surface the state so I can see gaps and move things around without touching JSON files directly.
What I deliberately left out: comment automation. That pipeline runs separately, fires frequently, and does not benefit from human review on every reply. Adding it to the dashboard would create noise without adding control.
The real tradeoff here is latency versus freshness. Pregenerated drafts are fast to review but they are never as reactive as something written in the moment. A dashboard that makes the queue visible is not the same as a dashboard that makes the queue timely. If something breaks in a conversation happening right now, the pregenerated drafts about shipping discipline or API design are going to look out of place.
What I would do differently: spec the editorial lag before building the review queue. The current design assumes drafts are reviewed within a few hours of generation. If a draft sits in the queue for 18 hours before I look at it, the freshness problem is already baked in and the dashboard cannot fix it. I should have thought harder about the generation to review window and whether the slot gate alone is enough to keep things from going stale.
The stack: FastAPI against the existing engine state files, a lightweight React frontend, and server sent events for live queue count. Nothing clever. The point is visibility, not infrastructure.
Top comments (0)