DEV Community

Toc am
Toc am

Posted on

I spent day two cutting a production cost that was already effectively zero

Sixteen days into this project the channel has 20 YouTube subscribers, one follower on two of the five platforms it publishes to, zero email subscribers and zero comments.

I spent day two of the project working out how to make an episode cost less to produce.

Both of those sentences are true at the same time, and that is the story this series is about. Here is the setup.

What I assumed

On 13 July I decided to build a faceless short-form channel full time, and to treat it as a compounding asset rather than a job of work with an invoice at the end.

The format is "Senior vs Junior". One coding problem, solved twice: the naive way and the veteran way. Vertical 9:16, split screen, panicked junior under red light on the left, calm senior in cool blue on the right. Tagline: "the difference between code that runs and code that ships."

The bet was technical accuracy. I have shipped production code in C, C++, C#, Java, JavaScript, TypeScript and VB. Anyone can generate a channel that looks like this one in an afternoon; what they cannot generate is a correct explanation of why the junior version falls over. Developer audiences sit at the top of the CPM tables, so accuracy in a top-CPM niche looked like the one defensible position available to a solo operator competing with automated slop.

The second assumption was quieter and it shaped everything that followed: I assumed the binding constraint would be credits.

What actually happened

The pipeline was proven on 14 July, one day after the decision. Four steps.

Generate a still frame for each block. Animate each still into an 8-second clip. Record one voiceover take per beat. Assemble the whole thing locally, syncing each block's audio to its own block and burning the captions in.

An episode is four blocks of roughly 10 seconds: cold open, junior code, senior code, the point. About 40 seconds end to end.

The same day, the funnel went live: a one-page site with email capture backed by a SQLite/D1 table, offering one senior tip a week. Then I built episodes 1 to 5 as a launch buffer before publishing anything at all, and Episode 1 went out on 17 July, starting on YouTube with the cross-posts following.

How I found out

I itemised the cost by stage rather than by episode: the still frames, the animation of each beat, the voiceover takes.

One stage dominates everything. Animating four beats at eight seconds each is the overwhelming majority of an episode's credit cost. The frames and the voice takes together are a rounding error beside it, which means the only lever worth pulling is the number of beats you animate.

The plan the account runs on carries roughly 3,000 credits a cycle, and puts an episode somewhere between 30 and 110 credits depending on how many beats get generated. Real builds sit at the top of that range, because frames come back wrong and get regenerated and animations come back unusable.

Now the part I read correctly and then ignored. The subscription renews whether I use it or not, and the plan's own reference does the arithmetic for you: at that per-episode cost, roughly 3,000 credits a cycle is about a hundred episodes before it runs dry. I was producing five. The marginal cost of one more episode was, in any sense that matters, zero.

So the number I spent day two optimising was already zero. I optimised it anyway, because on day two it was the only number I had that I could count. There were no views, no watch time, no signups and nothing in the D1 table to measure instead.

What I changed

Two decisions, both made on day two, both to cut credits.

First, reuse. Block 1 — the split-screen hook clip — is generated once and reused on every episode. So is block 4: the payoff card and the payoff voiceover that goes over it. Only the hook narration and the two code beats change from episode to episode. The stated rationale was brand recognition, a recurring open and sign-off that makes a catalogue feel like a channel. The real rationale was that it removed two of the four animated beats, which is roughly half the credit cost of an episode.

Second, one voice. A single preset voice — "Sterling" — reads every line of every episode. The junior, the senior, the hook, the payoff. One voice is one fewer variable in a pipeline I had just built, and consistency across a catalogue reads as a channel rather than a pile of clips.

Both decisions were cheap to make and both are load-bearing across all five launch episodes. Remember them.

What I'd tell you to do differently

Do the measurement, then check what the measurement actually said before you act on it. I got the credit accounting right, correctly concluded that marginal cost per episode was effectively zero, and then spent a day halving zero — because credits were countable on day two and the things that mattered were not. If the only number you can measure is the one that does not constrain you, the honest move is to publish sooner and let the platform hand you a number that does, rather than to optimise the one on your own dashboard because it is sitting there.


This is part of an honest log of building a faceless coding channel from zero.
The channel: https://www.youtube.com/@amtocbot
One senior tip a week, by email: https://seniorvsjunior.higgsfield.app

Top comments (0)