Video Production

Every coding.kitty video you watch is the last step of a pipeline: an idea goes in at one end, and a captioned, scheduled post comes out of the other. The stages are the same ones any team that ships something regularly ends up building, whether it ships videos or software.

Why a video needs a pipeline

A short video looks like one piece of work, but it is several jobs done in order: choosing a topic, writing a script, editing, adding captions and posting. Each job has a different input and a different output, and each one can go wrong in its own way.

When those jobs live in someone's head, three things happen. Ideas get lost, the same mistakes get made twice, and posting depends on someone remembering to do it. A pipeline fixes that by giving each job a clear stage, a clear handoff to the next one, and, where it makes sense, a tool or a script that does the repetitive part.

The coding.kitty pipeline has five stages:

1. An idea is submitted and lands on a Jira board.
2. Approved ideas go to a vote, and the top one is picked.
3. The script is written with custom tools, from rough idea to final draft.
4. The video is edited, then a subtitle burner adds the captions.
5. Software sends the finished video to the Buffer API, which posts it at the right time.

Stage 1: ideas on a board

The pipeline starts when someone submits an idea. It doesn't go into a chat thread or a notes app: it lands on a Jira board as a ticket.

A ticket gives the idea three things a message never has:

• A status. Everyone can see whether an idea is new, approved, being scripted or finished.
• A history. Comments, decisions and changes stay attached to the idea.
• One home. There is a single place to look, so nothing depends on scrolling back through old messages.

A Jira workflow is the set of statuses a ticket can be in and the moves allowed between them. For video production, a ticket might move through statuses such as 'New', 'Script in progress', 'Producing', 'In review' and 'Completed'. The board shows each status as a column, so the whole pipeline is visible at a glance: what is waiting, what is stuck and what is nearly done.

Picking what to make next

Not every idea becomes a video. If an idea is approved, it goes to a vote, and the top idea wins. Separating 'is this a good idea?' from 'what do we make next?' keeps the backlog honest: approval filters out ideas that don't fit, and the vote decides the order among the ones that do.

Stage 2: the script

Once an idea is picked, scripting starts. A short video has very little room, so the script goes through several drafts, from a rough outline of the idea to a final version where every line earns its place.

Custom tools keep the script moving between those drafts. The point of tooling here is not to write the script for you; it is to make the steps between drafts quick and consistent, so the effort goes into the words rather than the admin around them.

A good short script usually picks one angle and drops the rest. If a topic needs three ideas to make sense, it is often three videos.

Stage 3: editing

With the script locked, the video is edited: the cuts, the pacing and the timing. In a video under a minute long, timing matters more than in a long one. A pause in the wrong place loses the viewer, and a cut in the right place keeps them watching.

Editing is the stage that stays the most human. It is judgement, not repetition, so it is the least worth automating.

Stage 4: burning in the subtitles

After editing, a custom subtitle burner adds the captions right onto the video, so every word shows up clean and on time.

Soft subtitles and burned-in subtitles

There are two ways to put captions on a video:

Soft subtitles travel alongside the video, and the player draws them on top. They are flexible, but they only work where the platform supports the subtitle track.

Burned-in (or hardcoded) subtitles are drawn into the pixels of every frame. Once the video is rendered, the captions are part of the picture. They look the same on every app and every device, and they can't be lost when the video is uploaded somewhere else. The trade-off is that they can't be switched off, restyled or translated afterwards: changing a word means rendering the video again.

For short social videos, which many people watch with the sound off, burned-in captions are the safer choice.

A worked example

Timed captions are often stored as an SRT file. Each entry has a number, a start and end time, and the text to show:

1
00:00:00,000 --> 00:00:02,000
Kitty makes coding videos.
 
2
00:00:02,000 --> 00:00:04,500
But a video is not one step.

The times are hours, minutes, seconds and milliseconds, separated by -->. A subtitle burner reads entries like these and draws each line onto the frames between its start and end time.

FFmpeg, a widely used command-line video tool, can do this with its subtitles filter:

ffmpeg -i edited.mp4 \
  -vf subtitles=captions.srt \
  -c:a copy \
  captioned.mp4

-vf applies a video filter, so every frame is re-encoded with the captions drawn on. -c:a copy copies the audio as it is, because only the picture changes. A custom burner wraps a step like this so the font, size and position are the same on every video.

Stage 5: posting through an API

The finished video doesn't get posted by hand. The pipeline's software sends it to the Buffer API, a service for scheduling social media posts, and the post goes out at the right time.

An API (application programming interface) is a way for one program to ask another to do something. Here, instead of a person logging in, uploading the file, pasting the caption and picking a time, a program makes one request that carries all of that.

That swap matters for three reasons:

• Fewer mistakes. A program doesn't upload the wrong file or forget the caption.
• Better timing. The post goes out when the audience is around, not when someone happens to be free.
• One flow. The step that finishes the video can hand it straight to the step that schedules it.

Put together, the whole flow reads like a short program, with one function per stage:

def produce(idea):
    script = write_script(idea)
    video = edit(script)
    video = burn_subtitles(video, "captions.srt")
    schedule_post(video, when="18:00")

The real pipeline has people in it, at the vote, the script and the edit, but the shape is the same: each stage takes the last one's output and hands its own to the next.

The same idea as a software pipeline

If this sounds familiar, it is the thinking behind a CI/CD pipeline. Code moves through build, test and deploy stages, automated where it can be, with a clear handoff between each one. A video moves through scripting, editing, captioning and scheduling in the same way.

It also mirrors data pipelines, where raw data passes through steps that clean and shape it until it is ready to use. Swap 'raw data' for 'rough idea' and the shape is identical. And the final step, posting at a set time, is the same job a cron job does for code that has to run on a schedule.

Common mistakes

• Automating the wrong stage first. Start with the step that is boring, frequent and easy to get wrong, like posting or captioning. Leave judgement, like editing, to people.
• No single source of truth. If ideas live in a board, a chat and a spreadsheet, the board stops being trusted. Pick one place.
• Captions as an afterthought. On a muted feed, a video without captions loses most of what it says.
• Burning in captions too early. Burned-in text can't be changed, so burn them in only after the edit and the script are final.

Key takeaways

• A video production pipeline splits the work into stages: idea, vote, script, edit, captions and posting.
• A Jira board gives every idea a status, a history and one home, and its workflow makes the pipeline visible.
• Burned-in subtitles are drawn into the frames, so they show everywhere but can't be switched off.
• Posting through the Buffer API removes a manual step and gets the post out at the right time.
• The same stage-and-handoff thinking drives CI/CD and data pipelines.