# I Was Paying Descript $24 a Month. So I Built My Own Transcript-Based Video Editor > Source: > Published: 2026-09-24 07:55:56+00:00 I edit videos the same way I edit text. When I’m recording a video and say something stupid, repeat myself, or spend thirty seconds explaining something that should have taken five seconds, I don’t want to open a traditional timeline and start dragging clips around. I want to find those words in the transcript, delete them, and have the video change with them. That’s the workflow that originally made me start using Descript. And honestly, it’s one of those software ideas that feels obvious once you’ve used it. Your video already contains speech, your speech becomes text, and every word has a position in the video. So why shouldn’t editing the text edit the video? I was paying Descript around $24 a month and using it regularly. But after a few months, I started noticing something: I was paying for a huge product while using a surprisingly small part of it. I wasn’t producing complicated podcasts with multiple tracks. I wasn’t using AI voice cloning. I wasn’t collaborating with a production team. My actual workflow was incredibly simple: record a video, transcribe it, remove the parts I don’t like, clean up filler words, add captions, and export. That was basically it. Eventually I had the thought that every developer has at some point when using a SaaS product: **How hard would it be to just build the part I actually use?** So I did. I called it **transcriptcut**. The entire application is built around one simple idea: **edit the video by editing its transcript.** You upload a video and it gets transcribed. The transcript appears alongside the video, and every word knows when it starts and when it ends. That last part is more important than it sounds. If the transcript contains something like “today we are going to talk about pricing,” the application doesn’t need an AI model to understand where that sentence exists in the video. The transcription system has already given us the timestamps. If I select that sentence and delete it, transcriptcut takes the start timestamp of the first selected word and the end timestamp of the last selected word. That gives us the exact section that needs to be removed. From there, it’s just an edit operation. FFmpeg handles the actual video processing. There is no AI involved in deciding whether the correct section was removed. There doesn’t need to be. It’s just timestamps and arithmetic. And that’s what I like about this architecture. The interface feels intelligent, but the actual editing operation is deterministic. My first implementation actually went in the opposite direction. I built a free-text “Ask AI” command bar where you could type something like: *“Remove the section where I talk about pricing.”* The system would interpret the request, turn it into structured editing operations, validate those operations, and then execute them. I built an agent workflow for this with multiple stages responsible for understanding the request, generating the edit, validating it, and applying it. And it worked. I got the entire thing running end-to-end. Then I deleted it. That was probably the most useful product decision I made during the project. The problem wasn’t that the AI couldn’t understand the request. The problem was that I was giving an AI system too much authority over something destructive. Consider a request like: *“Make this video shorter.”* What exactly should happen? Should it remove the introduction? The outro? Long pauses? Repeated explanations? The AI has to make a judgment call. And if it makes the wrong one, your video has changed. When you’re generating a paragraph of text, an imperfect AI response is usually easy to fix. When you’re deleting parts of someone’s video, it’s a different problem. So I changed the design. Instead of allowing an AI agent to freely modify the video, transcriptcut focuses on specific operations. It can find long pauses, identify potential filler words, and surface things that might be worth removing. But the final decision stays with the person editing the video. The AI suggests something. I review it. I click approve. Then the application executes the edit. That led me to a principle that I now like much more than the original AI command bar: **Agents reason. Tools execute.** I don’t need an agent to decide what to do when the user has already told me exactly what to do. This project changed how I think about AI features in software. There is a strong temptation right now to turn every feature into an agent. Give the model some tools, give it a large prompt, and let it figure everything out. Sometimes that’s exactly the right approach. But sometimes you’re introducing complexity into a problem that doesn’t have any ambiguity. Transcript editing is a good example. Understanding speech is hard, so using an AI model for transcription makes sense. Determining whether a word such as “like” is being used as a filler word can also require contextual understanding, so AI can help there too. But once the user selects a sentence and presses delete, there is nothing left for an AI model to reason about. The application already knows the answer. That’s just software. I think that distinction is becoming increasingly important as we build more AI-powered applications. The goal shouldn’t be to maximize the amount of AI in a product. The goal should be to use AI where it actually adds something. If something is ambiguous, let AI help. If something is deterministic, write deterministic software. There was another reason I wanted to build this myself: I wanted my videos to stay on my machine. Video files are huge, and they’re often private. I didn’t particularly like the idea of uploading every video I wanted to edit to a cloud service just to perform a fairly simple editing workflow, so I made local-first a core requirement from the beginning. The architecture is deliberately simple. transcriptcut uses Next.js for the application, SQLite through Prisma for project data, the local filesystem for video storage, and FFmpeg for processing. There isn’t a managed database, object storage, or job queue sitting somewhere in the cloud. The project data and video files stay on the machine, while an AI provider is used only when inference is actually needed, such as transcription. When a video is uploaded, its audio is extracted and sent to the transcription provider. Once the transcript is available, editing happens locally through the timeline model. When it’s time to export, FFmpeg runs as a local process and creates a new video file without modifying the original. I also wanted the editing process to be non-destructive. When you remove a section from a video, transcriptcut doesn’t immediately rewrite your original video file. Instead, the application stores the edit as an operation. The original upload remains untouched while the project keeps track of what you’ve done. That means I can have a sequence of edits without destroying the source media. It also gives the application a much cleaner way to implement undo and redo because an edit is something that can be represented, replayed, and reversed rather than just a permanent modification to a large video file. Rendering is handled separately as an asynchronous job, so exporting a twenty-minute video doesn’t mean keeping an HTTP request open while FFmpeg does all the work. None of this is particularly revolutionary. And that’s kind of the point. I wasn’t trying to invent a new video codec or build a new rendering engine. I was taking technologies that already work well and putting them together around a workflow I actually care about. I want to be clear about something: transcriptcut isn’t a complete replacement for Descript. Descript is a much larger product, and there are many things it does that I have no interest in rebuilding. That’s actually one of the reasons I wanted to build transcriptcut. When developers think about replacing an existing product, we often imagine that we have to rebuild everything the original company built. I don’t think that’s necessary. I didn’t need all of Descript. I needed the small part that I personally used every week. Instead of asking, “How do I build a competitor to Descript?” I asked a much smaller question: **How do I build the transcript editing workflow I actually use?** That is a problem a single developer can realistically attack. And I think that’s an interesting way to look at software today. You don’t always need to build the entire category. Sometimes you just need to build the workflow. The other thing I found interesting was how quickly the project came together. The difficult parts of this application aren’t really mine. Whisper handles transcription. FFmpeg handles video processing. SQLite handles local persistence. Prisma handles the database layer. Next.js handles the application framework. Modern AI coding tools also make it much faster to explore ideas, write the surrounding code, debug problems, and iterate. That doesn’t mean building software has suddenly become easy. It means the cost of building a focused piece of software has become much lower. A few years ago, I might have looked at something like Descript and thought, “There’s no way I can build this.” Now I look at a product like that and ask a different question: **Which part of it do I actually need?** That’s a much more interesting question. Maybe you don’t need to rebuild the whole product. Maybe you need the 20% that you use 80% of the time. I’m not saying everyone should cancel their SaaS subscriptions and start rebuilding everything. There are plenty of products I happily pay for because they solve problems I don’t want to solve myself. But if you’re paying for a large product primarily because of one narrow workflow, I think it’s worth asking yourself what you’re actually paying for. In my case, I wasn’t really paying for a video editor. I was paying for a transcript-to-video editing workflow. Once I realized that, the problem became small enough to build. Now I have something I can run locally, change whenever I want, and keep improving without worrying about whether the feature I depend on will move to another pricing tier. And ironically, building it myself made me appreciate good SaaS products more. There are plenty of things I don’t want to build, and I’m happy to pay for them when I need them. But sometimes you don’t need the whole product. Sometimes you just need one workflow. The biggest lesson I took away from transcriptcut wasn’t really about video editing. It was about knowing when **not** to use AI. My first version was more impressive in a demo because you could type a sentence and an agent would figure out what you wanted. The final version is less impressive in a demo, but I trust it more. And for an editor, trust matters more than magic. If the application is uncertain about whether “like” is a filler word, AI can help. If I’m asking a system to understand a vague request, an agent can help. But if I’ve selected a piece of transcript and pressed delete, I don’t want an AI model making another decision. I want the application to do exactly what I asked. That idea started as a design decision for a small video editor, but I think it’s something I’ll carry into many of the products I build from here. I built transcriptcut because I wanted a simple, local-first transcript editor for my own videos. Now I’m making it open source. If you want to see how transcript-to-timestamp editing works, how the non-destructive editing model is structured, or you just want a local starting point for building your own video tools, the code is available at **github.com/amide-init/transcriptcut**. It’s still evolving, and I’m curious to see what other people do with it. Maybe you don’t need another video editor either. **Maybe you just need the 20% you actually use.** [I Was Paying Descript $24 a Month. So I Built My Own Transcript-Based Video Editor](https://pub.towardsai.net/i-was-paying-descript-24-a-month-so-i-built-my-own-transcript-based-video-editor-685e66750e44) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.