Content Pipeline System

Overview

Before this existed, content production and performance tracking lived in scattered places: a spreadsheet for post metrics, a running list for ideas, no shared source of truth for what stage a piece of content was actually in, and no way to compare a carousel against another carousel instead of the whole mixed dataset. The brief was to build one tool that could hold the entire lifecycle — idea, backlog, script, schedule, published, measured, plus paid-ad comparison and long-range project timelines — without becoming a heavyweight project-management product that fights how a small content team actually works. The result is a single self-contained web app, ten tabs, backed by a real database, built to be extended in small increments rather than shipped as a finished spec.

Ownership

• The product decisions — what to build, what problem it solves, how the tabs relate, what got cut and why — were mine. Implementation was AI-assisted throughout; I directed the architecture and reviewed every change rather than writing the underlying code myself.
• I personally designed the story-beat scripting framework: a Hook, followed by Chapters built from Beats (Vulnerability → Mechanism → Method → Takeaway), tagged with causal connectors ("Therefore" / "But") and persuasive levers, plus a CTA. This system has already been revised once after real use showed an earlier version wasn't working.
• I personally designed the analytics methodology: a self-calibrating color-coding system that ranks each post against the account's own historical performance on a five-tier scale, rather than fixed external thresholds — so "good" doesn't go stale as more data comes in.
• I caught and corrected a real architecture mistake mid-build: a paid-ads tracking tab was originally built as a mirror of the organic analytics tab, then rebuilt around the real schema once the actual historical ad data was located and didn't match the original assumption.

Proof

• A screen-recorded walkthrough with real narration exists, alongside a full authored methodology write-up documenting the architecture and the reasoning behind every tab.
• The live tool is a single self-contained file with no framework or build step, persisting to a database as structured records — a deliberate architectural choice to keep changes fast and readable at this scale (one user, one deployment target).
• All analytics are computed live from raw stored numbers at render time — nothing derived is ever persisted, so nothing can drift out of sync.
• Non-trivial logic changes are validated against a real historical dataset of 160+ posts before being considered done, specifically to catch calculation or indexing errors.
• A static, disconnected copy of the interface is live publicly below — same UI, no real data or database connection — so the design can be reviewed directly rather than taken on description alone.

Outcome

• Replaced a fragmented spreadsheet workflow with a single system of record for a distributed, multi-state team.
• Solved a real, dated measurement problem — a major platform's analytics changes had broken the prior tracking method — with a metric system that recalibrates itself instead of needing manual re-grading.
• Identified and fixed a real design flaw before it shipped broadly: an early version conflated "where is this in production" with "how good is it," which broke real workflows once review needed to happen more than once per piece of content.