Bootstrapping a YouTube Channel With Code
I decided to start a YouTube channel around one simple idea:
What is actually possible with code?
This project is mostly for fun. I want to explore YouTube as a platform and experiment with areas of coding I haven’t touched before. Instead of overthinking it, I’m learning by building in public.
And the first thing I’m building is the tooling for the channel itself.
Building the Tools First
The first series is focused entirely on bootstrapping the channel.
Instead of manually recording and editing everything, I’m creating small tools that help me produce better videos. I build the tools, use them to create videos, then improve them as I go.
Over time, I plan to make these tools available to others.
I’m also delegating as much of the coding as possible to AI tools.
Part of this journey is exploring how far AI-assisted development can go, and where it still needs human input.
The First Attempt
I wanted to create a welcome video with a clean terminal-style look.
So I opened iTerm and recorded myself typing the text.
It looked… bad.
Everything was off. The typing felt awkward. It wasn’t what I had imagined.
Here’s that first version:
Instead of trying to fix the recording setup, I decided to build something better.
A Simple Terminal Typer App
I wrote a small terminal-typer app that simulates typing and exports directly to video.
That way I can:
- Control timing
- Replay scripts consistently
- Generate clean output every time
Here’s how it looks like:
Using it, I recreated the welcome video, and it turned out much closer to what I originally wanted.
Here is the current version of the welcome video:
This is just the beginning.
Right now, I’m focused on building the foundation.
If you’d like to follow the journey, consider subscribing
And if there’s something you’d like to see me build, let me know.
If you watched the videos, you’ll notice they’re still silent.
Adding audio is one of the next steps in this experiment.
Top comments (2)
The terminal-typer app solving "my own recording looked bad" is the most honest origin story for a dev tool.
I went through a similar arc building a video pipeline for a dev channel — started by manually recording VS Code sessions, realized the output was inconsistent, ended up writing a Python script that composites code screenshots + Edge TTS narration + stock footage + burned-in subtitles via ffmpeg. One script replaced what was taking me 2-3 hours per video.
Two things I learned that might save you time:
Audio is harder than you think it will be. You mentioned silence as the next step — when I added TTS, the timing sync between "typing" visuals and narration became the actual hard problem. I ended up generating the audio first, then fitting the visual timing to the audio duration rather than the other way around. Counter-intuitive but it works.
The "make tools available to others" instinct is worth following early. I initially built everything as throwaway scripts. When I tried to package them later, the assumptions baked in (hardcoded paths, my specific ffmpeg flags, my font choices) made it painful. If you architect for "someone else will use this" from video 3-4 instead of video 30, you save a rewrite.
Curious about two things: are you generating the typing simulation frame-by-frame and then encoding, or rendering in real-time and capturing? And for the AI delegation part — where have you found the boundary between "AI handles this fine" and "I need to manually intervene"? In my experience it's roughly: script generation and boilerplate = great, anything involving pixel-precise timing or platform-specific encoding quirks = still human territory.
This is true for sure, last night I was struggling to sync audio and video. In the end I ended up making how I wanted, but it was painful. Also, that audio was as simple as it can be.
Totally agree here!
Currently experimenting with both approaches, but for now frame-by-frame works better.
My experience has been similar to what you described. AI has been very helpful for scaffolding, boilerplate, and structural work, but it struggles significantly with visual aspects and design related work.