I designed and built Clip Forge as an observable media-operations product spanning sourcing, rendering, publishing, verification, analytics and recovery.
Operations stateConceptual visualization, not production UI
OwnershipProduct + implementation
SystemRender to verification
Dataset313 publications
Run27 documented days
01 / Context
Why publishing became an operations product
Each platform had a different publishing flow, authentication boundary, limit and verification signal. Rendering could outlive a web request. A successful upload could still become a duplicate after a crash. Analytics could be incomplete. The central product problem was reliable coordination under partial failure.
Platform dependency
Different rules
YouTube, TikTok and Instagram expose different APIs, handoffs, limits and success signals.
Operational risk
False success
An upload response is not the same as verified publication, and a lost remote ID can trigger a duplicate.
Compute constraint
Long-running work
Local rendering and media processing do not fit an ephemeral web runtime or a single request lifecycle.
Learning constraint
Uneven evidence
Platform metrics arrive with different completeness, so experiments need explicit primary and secondary signals.
02 / Workflow
One pipeline, explicit lifecycle states
01Discover and qualify source
02Download and render 9:16 output
03Prepare metadata and schedule
04Publish and verify per platform
05Measure, compare and change rules
State model
Draft → processing → ready → publishing → published → verified or recoverable failure
Separate clip and platform states keep one failed handoff from corrupting the status of the full content item. The system persists durable identifiers at the earliest safe point and verifies downstream coverage before declaring completion.
Private product case. The system model and analytics are reconstructed from reviewed local product artifacts; no account credentials, private content or platform secrets are exposed.
Persist the remote video ID immediately after a successful upload, before later steps run, so a crash does not create a second upload.
Verified handoff
Keep separate TikTok and Instagram lifecycle states instead of treating a browser or API handoff as universal success.
Fail closed
Stop when the raster, rights state, platform limit or publication evidence is missing rather than guessing and publishing anyway.
Coverage recovery
Compare expected and observed outputs, then recover missing platform work without repeating completed work.
Experiment model
Attach a hypothesis, primary metric and secondary metric to content tests so the system can change based on evidence, not taste.
04 / Learning loop
What the data changed
A reviewed analytics snapshot contained 313 measured publications. It supported decisions about hook length, spacing, cadence and weighted content rotation. One comparison showed why the product needed a learning layer rather than a fixed schedule.
3.4-second hook
56 samples
62.5% success rate and an average of 36.3 views per hour in the reviewed sample.
3.0-second hook
76 samples
40.8% success rate and an average of 18.0 views per hour in the reviewed sample.
Product response
Change the rules
Analytics informed hook limits, spacing and a weighted rotation rather than producing a passive dashboard.
Measurement boundary
Correlation, not sole causation
Platform outcomes are reported as results of the documented system run, not attributed to one isolated design decision.
A documented 27-day run recorded 660,118 views and 1,040.1 watch hours while the channel reached nearly 28,000 total subscribers.
The result is useful because the system makes its operating decisions, lifecycle state and learning loop inspectable. Reach alone would not demonstrate product thinking.
05 / Product learning
The happy path is only one state
The durable design lesson is that automation quality depends on observability, idempotency, platform-aware limits and recovery. The interface must explain what happened, what is safe to retry and which external dependency owns the next action.
