Building Lede taught me more about software product development in 8 months than 5 years of running a video production agency. Not because the code was complicated, though parts of it were, but because the gap between a working tool and a product someone actually pays for is entirely different from the gap between a rough cut and a finished film. Here is what that gap looks like from the inside and how to cross it.
The Decision That Shapes Everything: Wrapper or Workflow Tool
The first real decision when building an AI application is whether you are building a wrapper or a workflow tool. A wrapper puts a user-friendly interface on top of an existing AI model. The user does not interact with the model directly. They interact with your interface, which sends their input to the model and returns the output in a way that is more useful than talking to the raw API.
Most AI applications being built in 2024 and 2025 are wrappers. Most of them fail commercially because wrappers without deep integration into a specific workflow get replaced by the next version of the underlying model. When GPT-4 made writing better, most AI writing wrappers lost their differentiation overnight.
Lede is a workflow tool. It does not simply send footage to an AI model and return a response. It is integrated into the specific steps an editor takes from raw footage to a structured rough cut. The AI model is one component inside a larger system that handles file intake, transcription, segment scoring, timeline assembly, and export optimization. The workflow integration is what creates the switching cost that a wrapper does not have.
Before you write a single line of code, decide which one you are building and why the workflow integration you are building cannot be easily replaced by a model update.
The Technical Stack Decision for a Non-Technical Founder
Building a desktop AI application from scratch requires decisions across 4 technical layers. The application layer, which is what the user sees and interacts with. The processing layer, which handles the actual AI computation. The storage layer, which manages files and job states. And the deployment layer, which determines how the application reaches users and stays updated.
For Lede, we chose Electron and React for the application layer because Electron allows a single codebase to produce a desktop application for both Mac and Windows. React is the most widely supported front-end framework with the largest community for solving interface problems. The learning curve for Electron is real but the cross-platform output is worth it.
For the processing layer, we use a Railway worker running Node.js with FFmpeg for video processing and Whisper for transcription. Whisper handles audio-to-text with accuracy levels that made it the obvious choice for an application where the quality of the transcript directly determines the quality of the rough cut. The Railway worker runs in the cloud, which means the user’s local machine does not need to be powerful enough to run the processing itself.
For storage, we use Backblaze B2 for video files and Supabase for job tracking. Backblaze B2 is significantly cheaper than AWS S3 for large file storage, which matters in a video application where file sizes are measured in gigabytes. Supabase provides the real-time job status updates that let the user see their rough cut assembling in progress without polling a server every second.
The Hardest Problem Is Not Technical
After 8 months of building Lede, the hardest problem we solved was not the code. It was the question of what the product should do when the AI gets it wrong.
AI tools make mistakes. Whisper misidentifies words. The segment scoring algorithm sometimes keeps sections it should cut and cuts sections it should keep. The first version of Lede was built as if the AI was always right. The result was a rough cut that editors did not trust and therefore did not use as a starting point. They re-edited everything from scratch.
The version that worked was built around the assumption that the AI gets it right 80 percent of the time and the editor needs a fast, clean way to fix the other 20 percent. Adding a review layer between the AI assembly and the export changed the adoption rate from near zero to consistent daily use among the beta testers we brought in from the Brand 4:44 team.
Build your AI application around the assumption that the AI will be wrong some percentage of the time and give the user the fastest possible way to correct it. The applications that fail are the ones that treat AI output as final. The applications that users adopt are the ones that treat AI output as a very strong first draft.
What Launching an AI App Actually Takes
The technical build is 40 percent of the work. The other 60 percent is documentation, onboarding, customer feedback systems, pricing research, payment infrastructure, update distribution, and support. Most founders who build AI applications underestimate this ratio by a factor of 3.
Budget twice as long as you think the build will take. Budget twice as much for the post-build infrastructure as you budgeted for the build itself. And get the product in front of 5 to 10 real users who match your target customer profile before you spend a single dollar on marketing.
The users who will tell you what the product actually needs to do are the ones who try to use it for real work and hit the walls you did not know existed.