How I Built a Content Factory Before I Had a Product

Most founders build the product and then figure out how to talk about it.

I built the factory first.

Not because I had a grand content strategy. Because I tried to figure out a workflow that Replit uses, React components animated with Framer Motion, rendered to MP4 via Remotion, and thirty minutes later I had a local folder, a git repo, docs, and a first-pass motion graphic video sitting on my machine. The tooling was that fast. The decision to keep going was obvious.

Fourteen videos later, in duplicate for platform sizing, with a matching set of stills in duplicate, and a subfolder system containing screen-grabbed context from every element of the Deployed Works site, blogs, help guides, product copy, I had a complete distribution infrastructure for a product that had not yet published a single page.

That sequencing is not accidental. It is the principle.

Build the Factory, Then Run It

The standard advice is to launch first, then build the content operation around what lands. The problem with that approach is that content without a production system is always reactive. You are always catching up to the product, always adapting assets one at a time, always losing the thread between what the product claims and what the content actually says.

Building the factory first inverts that. By the time Deployed Works was live, every surface had a motion asset, a still, a platform-sized variant, and a content context folder that captured the exact language, visual hierarchy and claims structure of the site at launch. Nothing needed to be retrofitted. The distribution was ready before the product needed distributing.

That is not a content strategy. It is an operational decision about sequencing.

Codex as Operating Partner

The tooling that made this possible was not just Remotion. It was Codex, used less like a code assistant and more like an operating partner.

Not: write me a blog post. More like: here is the product argument, here is the brand language, here is the claims guardrail, now generate the framework that turns this into a guide, a help video script, a LinkedIn post, an Instagram caption, and a Remotion prompt, all from the same source material.

The breakthrough was treating prompts as operational artifacts rather than disposable chat messages. Every major content or product slice became a prompt document: buyer brief flow, provider profile structure, guide pages, social sharing logic, motion studio parameters, deterministic matching GTM. Those documents live in a local folder alongside the codebase. They are version controlled. They are the memory of every decision made about how to talk about the product.

The README is the index. Google Drive mirrors the working docs. The folder is the operating system.

One Argument, Many Assets

The principle underneath all of this is simple. One product argument should become many assets without being rebuilt from scratch each time.

A single well-structured product claim, that the briefing is the product, that capability is broader than employment, that matching should be explainable rather than algorithmic, becomes a guide section, a help video script, a Remotion animation prompt, a LinkedIn post, an X post, an Instagram caption, and an outreach snippet. The argument is the same. The format changes. The factory handles the translation.

This only works if the source material is structured correctly from the start. Codex enforces that. Not by writing the content, but by maintaining the framework, the brand language, the claims structure, and the handoff prompts that keep every output consistent with every other output regardless of format or platform.

When Codex is doing that job well, product, GTM, content and engineering stop being separate tabs. They share the same context, the same language, the same understanding of what has shipped and what has not, what is public copy and what is internal truth.

The Motion Pipeline

Static idea. Remotion prompt. React component with Framer Motion. MP4 output. Platform-sized duplicate. Still export. Platform-sized duplicate of the still.

That is the pipeline. It sounds mechanical because it is. Mechanical is the point. Once the pipeline exists, generating a new asset for a new product surface takes minutes rather than days. The creative decision is made once, at the prompt level. Everything downstream is execution.

The dark and light variants for the Instagram grid, the LinkedIn and X social copy that travels with each video, the caption that matches the visual, all of that comes from the same prompt document that produced the motion brief. Change the prompt, regenerate the pipeline. Nothing needs to be touched by hand.

What This Actually Is

This is not a content marketing post. It is a post about operational infrastructure and the decision to build it before you need it.

AI agents are most useful when they manage structure, continuity and repeatable workflows. Not when they generate isolated pieces of content on request. The difference between those two uses is the difference between a factory and a printer. A printer produces one thing at a time. A factory produces everything from the same tooling, consistently, at whatever volume the moment requires.

I built the factory before I had a product to run through it. By the time the product was ready, the factory was already warm.

That is the sequence worth stealing.