# Camil > Removes any sound you can describe from your videos - Canonical URL: https://indie.md/people/camil/ - Products: SoundScrub (https://soundscrub.video) ## Bio Builder of SoundScrub, a desktop app that removes any sound you can describe (a barking dog, people talking, copyrighted music) from a video, or keeps only that sound, or just turns it down. It runs on Meta's open-source SAM Audio model inside an Electron shell with a Python backend on RunPod, and by design the video never leaves your machine: only the extracted audio is uploaded for processing. Started as a terminal script for cleaning up his own holiday footage and grew into a pay-per-use product aimed at travel vloggers and videographers. ## Journeys - [SoundScrub: From a Terminal Script to a Product](https://indie.md/journeys/camil-soundscrub/): How a tool for cleaning up holiday footage became a focused app that beats the big editors at one job ## Events - [Indie TM #10: Four Builds and the Reach Problem](https://indie.md/events/indie-tm-10-timisoara-june-2026/): 2026-06-10 ## Advice ### A personal fix becomes a product when others share the pain SoundScrub began as a script Camil wrote to clean the background noise out of his own holiday footage. The leap to a product came from one question: do enough other people have this exact pain? Scratching your own itch is a great way to start, but it only becomes a business when you confirm the itch is widely shared and worth paying to scratch. Build the thing that solves your problem first, because you understand it deeply, then go check that travelers and videographers are loudly describing the same problem before you commit to productizing it. Source: https://indie.md/advice/from-personal-fix-to-product/ ### Wrap your script in an app for the people who fear the terminal Camil's noise-removal script already worked; the product was wrapping it in a desktop app for everyone who would never touch a terminal. The market for a command-line tool is other developers; the market for the same capability behind a clean interface is everyone. If you have a script that genuinely solves a problem, the productizing work is mostly removing the technical barriers around it, not adding features. A good interface over a working script reaches an audience an order of magnitude larger than the script ever could. Source: https://indie.md/advice/wrap-your-script-in-an-app/ ### Stand on an open model and build the experience around it SoundScrub's audio separation is powered by Meta's open-source SAM Audio, not a model Camil trained. The leverage for a solo builder in 2026 is enormous: the hardest research is published and free, so your job is the product around it (the interface, the workflow, the trust). Do not try to out-research a frontier lab. Find the capable open model that does the hard part, and compete on the experience, the focus, and the polish that the raw model will never have on its own. Source: https://indie.md/advice/build-on-open-models/ ### Let your architecture hand you a feature worth selling SoundScrub uploads only the extracted audio, never the video, and deletes it right after, so users get a real privacy guarantee that fell out of the technical design rather than a marketing decision. When a property of your architecture happens to answer a fear your users have (privacy, speed, offline use), name it and put it on the page. The most credible selling points are the ones that are simply true because of how the thing is built. Look at your own stack for promises you can already make and are not yet making. Source: https://indie.md/advice/turn-architecture-into-a-promise/ ### Be honest about the limits of your tool Camil told the room exactly where SoundScrub breaks down (no spatial selection, a practical clip-length limit) and it made his strong claim, that it beats DaVinci Resolve at isolating a named sound, more believable, not less. Naming your limits signals that you understand your own product and are not overselling, which is precisely what makes your genuine advantages credible. Buyers trust a founder who volunteers the edges. Hiding the limits only means the user discovers them later, at the worst possible moment, and stops trusting everything else you said. Source: https://indie.md/advice/name-your-tools-limits/ ### A focused tool can beat a feature buried in a giant suite Every video editor already owns a do-everything suite, so the instinct is that a single-purpose tool has no room to exist. SoundScrub is the counterexample: it isolates and removes any sound you can name, and it does that one job noticeably better than the audio isolation built into DaVinci Resolve. Editors will keep their main editor and still pay for a focused tool when it does a specific painful task markedly better than the all-in-one does. The play is not to compete with the suite on breadth, it is to find the one operation the big tool does badly and own it completely. Depth on a single job beats breadth across many when the job hurts enough. Source: https://indie.md/advice/single-purpose-tool-beats-suite-feature/ ### Sell where people already describe the problem You do not have to create demand for SoundScrub; people generate it daily in their own words. Travel vloggers get demonetized over background music, videographers fight wind and crowd noise, and they post the exact symptom on Reddit and YouTube: how do I remove this sound from my clip. The distribution move is to show up in those threads with a genuinely useful answer and a tasteful mention of the tool, because the audience that is already typing the problem is pre-qualified in a way no cold ad audience ever is. Search for the complaint, not the keyword: every post that describes your problem out loud is a warm lead and a free piece of validation. Be helpful first and the plug forgives itself. Source: https://indie.md/advice/sell-where-people-describe-the-problem/