Always be dogfooding, with Andrew Lisowski of devtools.fm
Andrew Lisowski built a video-editing feature into Descript for his own podcast, expecting it to save him time. It didn't — automation always costs more upfront than you think — but it went on to save Descript's customers thousands of hours of mindless clicking.
Andrew Lisowski co-hosts devtools.fm, a podcast about developer tools and the people who build them, alongside his day job as an engineer at Descript. He's also maintained several widely-used open-source projects, including Jimp, the JavaScript image manipulation library.
We get into how dogfooding his own company's product turned into a genuine engineering advantage, why he's rebuilt the same personal side project — a Storybook-style static site generator — eight times without ever really shipping it, and the very unglamorous economics of actually running a podcast, from Patreon's dead end to how Raycast signing on for 20 weeks legitimized the whole thing.
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.
What's your first-hand experience maintaining a widely-used open-source project?
My first real dive into open source was Jimp, a JavaScript image manipulation library that had languished for about two years because its creator was transitioning from developer into local politics in Cork, Ireland. There were hundreds of open issues, and early in my career I idolized the people I saw as titans of the npm ecosystem, so I wanted to dip my toe in. Through maintaining Jimp I've ended up with billions of npm downloads, just from keeping it working on the latest Node and making sure it stayed a fun thing to use. Maintaining is a different skill from building, though — anyone who likes programming can ship a library, but knowing when to say no to a contribution is something you only learn by doing it. Early on you take every addition, because people are asking you for things and that feels good. Later you realize every merged feature is something you now own and have to maintain forever, and if you want to make a breaking change, you have to account for all of it. Some of my early projects still show that in their bloated core — where I'm at now, I'd say no a lot more.
How do you personally manage the workload of maintaining open source now?
Less than I used to — my old job explicitly paid me to do open source, so I created and took on a lot of maintenance burden. GitHub notification anxiety is a real, well-documented phenomenon once your notifications run into the thousands of mostly people complaining at you or requesting things — that red dot started giving me real anxiety over time, so now I check in maybe once a week or once a month rather than engaging constantly. I prioritize PRs over issues: if someone submits a PR and it's something I'm okay with, I'll review and merge it. For an issue, I'll often just say 'that seems like a problem other people have too — PR welcome' rather than committing to fix it myself.
You've said dogfooding is one thing you truly believe in. What did that actually look like at Descript?
When I started using Descript to edit my own podcast, we'd just added video with multi-camera sequences, and getting the editing behavior I wanted — my face on screen when I'm talking, Jack's face when he's talking — took an hour and a half of clicking for a one-hour podcast, and I could feel my wrist starting to hurt. So one weekend I decided to just code the feature myself, telling myself it'd take about as long as doing it manually one more time — which, like most automation, wasn't true, it took much more time upfront. But that feature has probably saved our customers thousands of hours of mindless, error-prone clicking. Every week editing my own podcast, I file two or three bugs on a good week, up to a dozen on a bad one, because I've developed laser vision for exactly what the product should be — I helped build the design system too, so I can spot something two pixels off immediately.
Did that dogfooding translate into real influence inside the company?
It's been strange in a good way — I have a large body of Descript-specific work that people know about internally, so people randomly ask if they can use my podcast files for something, and I keep popping up in places, like the CEO's product announcement videos needing a multi-track sequence example. When we shipped an AI clips feature, I mentioned at an offsite that I hadn't used it much yet, and the AI team said, 'you're the one person who should be using this — we trained on your footage. If it's going to work well for anybody, it's going to work well for you.' It's a strange scale for a personal dogfooding habit to end up mattering at. It's the same story for internal dev tools — we built our automated release tool because we needed it ourselves for a bunch of monorepos, used it heavily until it was battle-tested and solid, and only then felt comfortable opening it up to add support for other languages.
What pattern have you noticed across the guests you've interviewed on devtools.fm?
People have obsessions that don't necessarily produce a company or a tool in year one — sometimes it takes the sixth time rebuilding the same thing before they land on something that actually works, folding all the previous failures into the new attempt. My advice to junior engineers is the same: go build a bunch of side projects, they'll mostly fail and go nowhere, but you'll learn a lot. My own obsession lately has been static site generators and Storybook alternatives — I've built eight of them at this point, and even though none has become a tool anyone but me and a few people at my old job use, I learned webpack entirely through building my first documentation generator, to the point that being 'the webpack guy' became part of my actual job. That came from side project after side project that nobody asked for and nobody but me cared about.
How do you prepare for interviewing a guest, especially someone with a big following like DHH?
Basically the same process for everyone: I go to their Twitter, open every link I can find, and just start reading. For DHH, a lot of that episode ended up focused on his recent programming takes, so I read the blog posts behind them and had questions ready, including on the TypeScript drama he'd been part of. We tell every guest at the start of the episode to talk as long and as deep on anything as they want, and he really ran with that — there were twenty-minute stretches where my co-host and I said almost nothing, just steering him back toward where we wanted the conversation to go rather than inserting our own rebuttals. That ended up being our biggest episode by far — DHH's following reacts to him in a way I don't think anyone else in tech gets; the YouTube comments are just people saying they love every word he says.
What's the actual cost structure of running a podcast, and how did you make it sustainable?
It's not free, and it's always more work than you think, even after you hire help — an editor just frees you up to do more different things, not less. If you don't have at least four hours a week for it, you probably shouldn't start; releasing every other week instead of weekly lessened that burden a lot for us early on. We tried Patreon for about a year and got $140 a month — barely enough to pay for editing one episode — and it felt genuinely bad on both ends: cutting a free episode down to 45 minutes by removing chunks that could still flow felt like shortchanging a guest who gave us their time, and it felt odd charging our own fans money at all. Sponsors turned out to be the real answer — when we announced we wanted sponsors, Raycast signed on for 20 weeks without even negotiating on price, which legitimized the whole show. We've since had Codecrafters, Clerk, and Mux, usually on 10-week runs, and now guests sometimes ask to sponsor an episode themselves before we even bring it up.
What would you tell a devtools company thinking about starting their own podcast for community building?
Look at what companies like Jam are doing — a lot of devtools startups are fundamentally about community, building a group of people excited about what you're making, and Jam's podcast is basically hour-long testimonials from real users combined with events and community activity that brings more people in, which can't be a bad thing. As for what makes a good episode, it's less mysterious than it feels in the moment — I often finish recording convinced an episode was terrible because I said one thing wrong, then watch it back in editing and realize it was actually a great conversation. Most people are interesting if you ask the right questions, and honestly, good questions are almost a form of manipulation — I do enough research that I'll sometimes ask something knowing exactly what rant it's going to trigger, and steer toward that on purpose.