Founder · AI product and operations
RavenClip: From a personal tool to paying customers.
I founded, built, and operate a product that turns news into short videos and publishes them to YouTube Shorts and TikTok.
- 105days
- from first commit to first external paying customer
- 3
- paying customers as of 26 September 2026
- 2
- live publishing platforms: YouTube and TikTok
First commit: 24 May 2026. First external payment: 6 September. Customer count: 26 September.
The short version
- 01WorkflowWeek 3It ran on a schedule and published on its own.
- 02Customers105 daysFrom first commit to the first external paying customer.
- 03RecoveryResumeEach stage saves its status, so a failure picks up where it stopped.
- 04Fallback25 daysA provider ran out of credit and fallback hid it. Monitors now catch this.
- 05AI checksReview staysChecks catch structure and length. Customers keep review for the facts.
- 06Cost$0.36Recorded API spend per rendered video, 1-25 September 2026.
Start with a complete workflow
I wanted a simpler way to follow the news myself, so I built the whole flow first.
The first weeks
- First version: a complete video, with each stage started by hand.
- Week three: it ran on a schedule and published on its own.
- Around then: I built a manual story picker, and removed it the same day.
The priority was a channel that keeps publishing while its owner is busy. More controls could come once that worked.
Learn from the people who pay
I first pictured creators running news channels. The people who paid first were different.
Who I pictured
- Creators running news channels
Who paid first
- An agency
- An AI consultancy
- A coach
So I moved the product toward businesses that build an audience around their expertise.
What I added for them
- Brand controls
- More channels per account
- 105 days
- from first commit (24 May 2026) to the first external payment (6 September)
- 3
- paying customers as of 26 September 2026
- 30 / 30
- posts from those customers published automatically, as of 26 September 2026
Three customers is an early signal, and I treat it that way.
Choose architecture around recovery needs
A video passes through several paid services. Restarting after one failed step would throw away finished work and pay for it twice.
voice branch
visual branch
Voice and visual work run in parallel before rendering. Persisted stage results let retries reuse completed work. Publishing runs automatically or after customer review, according to the channel settings.
Saved stages
Each stage saves its status. A runner moves forward whatever is ready.
One worker per stage
Database locks stop two workers from taking the same stage.
Reuse on retry
A failed render reuses the assets it already has.
Publish once
Publishing has its own guard against duplicate posts.
When I skip it
All this means more state and recovery code to maintain. For a short rebuild that a user starts, a simple job chain is enough.
Notice when fallback hides a problem
Fallback kept videos coming, so nothing looked wrong.
Define what AI checks can prove
Automatic checks catch a lot, but not everything. So customers keep the final say.
Checked
- Script structure and length
- The story stays about its subject
- The approved narration is not changed later
- On-screen figures come from data sources, not the model
- Retries are told exactly what to fix
Not proven
- Every factual claim. So customers keep review controls, and flagged videos wait for approval.
- $0.36
- recorded API spend per rendered video: 183 videos, 1-25 September 2026, without payment fees or my time
- 19
- content categories
- 5
- interface languages. Paying customers so far publish in English and French.
Publishing
- TikTokLive
- YouTube ShortsLive
- InstagramBuilt, waiting on app review
The engineering decisions and operating lessons, in more detail.
Read the postProduct walkthrough
Visit RavenClip
