CutBrief: the paid edit should not start with a guessing game

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle What I Built "Make it engaging. Add captions. Something clean." That is a message, not an editing brief. It does not tell an editor which footage to use, what the opening should do, or what the viewer should do next. When the first cut fills those gaps differently from the client, the revision starts before the real work has settled. I run a short-form editing agency. For this week's Side Hustle theme, I chose a problem close to the work: getting from a rough client request to a handoff an editor can actually use. CutBrief is a small browser tool. Paste a request, select an editing direction, and a local open-weight model suggests a hook, cut plan, caption notes and a CTA check. The result is editable and downloadable as plain text. The important choice is what it does not blend together: The client's exact request stays at the top. AI ideas are labeled as suggestions, not client instructions. A fixed checklist asks about assets, deadlines, scope, revisions, rights and fees. The model does not quote a price, promise results, contact the client or edit the video. It helps prepare the brief. The editor still owns the decisions. The buyer hypothesis is a freelance editor or small editing studio doing repeated short-form work. They would pay for a better handoff if it reduces clarification and rework. I have not validated that hypothesis with a paying customer. A plausible product is a one-time studio setup with its own brief format and vocabulary, rather than another per-token subscription. That is a business idea to test, not revenue I have earned. Demo Try it here: https://sanny1921.github.io/cutbrief/ The first load downloads model files (hundreds of MB) and needs a WebGPU-capable browser, so older phones may not work. Nothing is sent to an inference server. The included cafe request is fictional. It asks for a 30-second brunch reel, a warm style, food close-ups, licensed music and a visit-us CTA. It is example input, not customer feedback. The intended flow is: load model, paste request, generate, review against the original, edit, then export. The two review boxes are a reminder to check facts and the final agreement, not a claim that the model can verify them. Code Repo: https://github.com/Sanny1921/cutbrief (public, MIT). The README lists the limits. The app code is MIT licensed. Qwen and WebLLM have their own Apache 2.0 licenses and are credited below. CutBrief is a new Week 2 project, not a change to my Week 1 app. How I Built It The UI is HTML, CSS and JavaScript, with inference in a module worker so model work does not need to block the interface. It uses Qwen2.5-0.5B-Instruct, an open-weight model from the Qwen team, through WebLLM 0.2.84, MLC's open-source in-browser inference engine. The selected MLC build is Qwen2.5-0.5B-Instruct-q4f32_1-MLC. The prompt is deliberately narrow. It asks for four short sections and tells the model not to invent client facts, prices, offers or guarantees. User input is marked as request data. That reduces accidental instruction mixing, but it is not a guarantee against bad output. The app keeps the original source visible so the person reviewing has something to check. A small model is a tradeoff. It is cheaper to load than a much larger model, but it is not a reliable substitute for an experienced editor. The product is useful only if reviewing its ideas is less work than writing the handoff from scratch. What has actually been tested The responsive UI was checked at 320px, 390px and desktop widths. Example loading and clearing work. In a test with an explicitly labeled model substitute, edited output exported exactly and the review gate blocked unchecked export. That checks the app mechanics, not the quality of AI. I also ran it on a real phone: a Motorola edge 60 pro in Chrome on Android. The model downloaded and loaded, and I loaded the fictional cafe example and tapped "Make an editing brief". It produced a real AI-generated brief with the client's exact request at the top, the selected direction, and a separate "AI SUGGESTIONS (not confirmed client instructions)" section. The screenshots below are from that run. That is one device and one fictional example. It shows the whole local flow can work on a current Android phone. It does not show that the suggestions are good, that other phones will cope, or how fast it runs on them. I did not benchmark it. Earlier, on a software GPU, completion did not finish within my bounded test, so hardware matters. Why Does Open Innovation Matter? The brief may contain a client's unreleased offer, creative direction or launch plan. For a text task this small, shipping those words to a hosted model should be a choice, not the only way the product works. With local inference, the client request is passed to the model in the browser. The app has no message database, analytics or inference server. Hosting, JavaScript-CDN and model servers still receive ordinary file requests and IP metadata. The first model download needs internet, and I do not claim that a page reload always works offline. Open weights also change the cost structure. There is no hosted-model charge for each generated brief. That does not make the product free to operate: the user's device, storage, electricity, setup and support still cost something. It does make a one-time studio tool more plausible without attaching a token bill to every client's request. The model and prompt can be changed without rewriting the handoff workflow around one proprietary inference provider. Qwen's Apache 2.0 license and WebLLM's Apache 2.0 license make that path inspectable. I have not fine-tuned this model; studio-specific tuning is a future option, not an implemented feature. The open approach is better for this design's data boundary and per-request API costs. I have not demonstrated that it writes better briefs than a closed model. A larger hosted model might produce stronger suggestions and work on more devices. Local inference has a real entry cost: hundreds of MB to download, a WebGPU-capable browser, and hardware-dependent speed. That is the constraint I want to test honestly. A small, private draft assistant might be enough for the handoff. It does not need to become a video editor or a general chatbot to earn its place. Credits Qwen2.5-0.5B-Instruct model card and its Apache 2.0 license. MLC model conversion. WebLLM, Apache 2.0, by the MLC team. Built with AI assistance. Customer validation is still a next step. No first-user, payment or partner-prize claim is included.