Developer video for startups with Richard Moot from Square
Richard Moot's screencasts look comically oversized on his own monitor while editing — huge fonts, generous margins, nothing like a normal desktop. He's learned not to trust what looks right on his screen, because by the time it's compressed into a YouTube embed, that oversized text is exactly what makes it legible.
Richard Moot is head of developer advocacy at Block (Square), running Square's developer YouTube channel.
We get into the unglamorous fundamentals of good developer video — audio quality above everything else, why building clean code examples is consistently the hardest and most time-consuming part, the specific division of labor between a developer advocate and a video editor who doesn't understand the code being shown, and why he thinks enjoying the process is a genuine production value, not just a nice-to-have.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
If a startup is just getting started with developer YouTube content, where should they actually begin?
I'd assume you've already got some traction with blog content and understand your audience before jumping to video, though that's not a strict prerequisite. The single most important, and most overlooked, thing is audio. If you're recording yourself, get a genuinely good microphone and record somewhere that isn't echoey — even for something as simple as a screencast demo. My editor and I will nitpick audio relentlessly, because we know for a fact that people won't watch a video that sounds tinny or robotic, no matter how good the content is.
Beyond audio, what else matters early on?
Plan more than you'd initially think you need to. Some developers record themselves doing something first and edit it down with a voiceover added afterward — that might work for some people, but it's never worked for me; I want to know exactly what I'm doing ahead of time so I have it well planned, and later I'm just doing fine edits. I'd also recommend ScreenFlow as a tool — not expensive, and it gets you 90% of the way there. Our whole team records our own screencast segments ourselves, because we're the only ones who really understand how the code should look or behave, and ScreenFlow lets you quickly scribble out a typo or fix a small mistake in the edit without much fuss.
Video production involves a lot of different skills. How do you divide responsibilities between a developer advocate and a dedicated video team?
We were fortunate to have an existing video team that had already worked on Square's main brand channel, and they showed us what genuinely good video production could look like, rather than us going scrappy with an outside agency as originally planned. Developer advocates already know how to teach someone to use the software and write the code — that's the core domain expertise. Asking the same person to also record, edit, sync audio perfectly, and do all the post-production work adds hours and hours that aren't really what you're paying an advocate for. Getting a dedicated video editor matters, but it's a genuine translation challenge — I'll be explaining something like tokenizing a form and passing it to an API, and my editor has no idea if I even said that correctly. We have other advocates doing script review specifically to catch technical accuracy, while the video person is separately thinking about whether the shot itself came out clean.
What visual and design standards have you found matter most for screencasts specifically?
Come up with your own consistent aesthetic standards and stick to them — clean up your desktop entirely before recording, don't leave distracting windows open, keep consistent margins and aspect ratio every time. The single biggest lesson for us was making fonts much bigger than instinctively feels right. You have to think about every place the video might end up — embedded in a blog post, in documentation, or watched in a small YouTube player rather than full screen. When I record something myself, everything looks comically oversized on my own monitor, and I keep telling my designer it must be wrong — but once it's compressed down into the actual YouTube embed, it turns out to be exactly right and perfectly legible.
You've said building code examples is one of the hardest parts of making a good developer video. Why?
I think of good examples as treasure — once you have one, the rest of the content flows much more easily, though I don't want to pretend everything after that becomes trivial. The code has to look genuinely clean and be as succinct as possible, and if you have animations or transitions, they need to flow smoothly too — getting that level of precision is critical, because a small bug will drive you crazy every time you revisit that video, and eventually someone will call it out in the YouTube comments. Building the example is really a precursor to the entire video — once the code is finalized, you can finally write the script, because you know exactly what you're going to talk about. It's part of why we eventually hired a dedicated developer relations engineer just to focus on building examples — every time I've had to build one myself for a video, it takes two to three times longer than expected, purely from writing and refactoring the code before I can even start scripting.
How do you think about quality versus quantity when starting out with video content?
There's real value in spending time upfront figuring out what a genuinely quality video actually requires, the same way you'd figure out what a truly good blog post requires, before trying to scale volume. Our first few videos were genuinely hard to put together — working with a team building out physical sets, insisting on a certain level of quality even when it would have been easier to cut corners — but that investment paid dividends long term. Once you've hit that quality bar once, you start understanding exactly where you can safely cut corners without meaningfully hurting the result — I learned little tricks, like pasting all my values into a screen recording first, then using undo and redo to make the paste sequence look seamless on camera. You earn those shortcuts by doing it the hard way first; you don't get them for free.
You've mentioned that having fun while making content actually matters for the final result. How so?
It's partly selfish — I want to enjoy my own job, and if my job is creating content, I want that process to be enjoyable. But I also genuinely believe that if you're having fun, or at least genuinely find something interesting, that comes through in the finished content — obviously that doesn't apply to something like walking through a security vulnerability, where a lighter tone wouldn't fit, but wherever it's appropriate, it's worth leaning into. The best content I want to share with someone else is always content where you can tell the creator was genuinely into what they were making. There's probably a real psychological effect too — when you're deliberately trying to enjoy the process, the creative work tends to flow better. Even mid-shoot, if someone flubs the same line repeatedly, we'll stop, take a breath, chat about something completely unrelated for a minute, and come back with the anxiety reset and the enthusiasm genuinely restored.