This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend
What I Built
I built EditFlow, an open-source-AI workflow copilot for freelance video editors.
I built it for a friend who works with client-driven video editing workflows, where the hardest part isn't always editing the video — it's keeping track of what the client actually asked for.
Client feedback often arrives as a messy combination of messages, revisions, changing decisions, and vague requests:
"Make it cinematic."
"Use clip 12."
"Actually, use clip 18 instead."
"Keep it around 60 seconds."
"Actually, make it under 30 seconds."
EditFlow turns that conversation into a structured editing project.
It extracts:
- Requirements
- Revisions and changed decisions
- Contradictions that need clarification
- Actionable editing tasks
- Evidence linking each decision back to the original client message
The goal isn't to replace the editor.
It's to make sure the editor doesn't lose track of what the client actually said.
Demo
Live Demo: https://editflow-5e6s.onrender.com
The demo includes a sample wedding-reel conversation showing how EditFlow turns client messages into requirements, revisions, conflicts, and tasks.
The application also includes a deterministic Demo Mode fallback so the workflow remains usable when an external AI inference request fails.
Code
GitHub: https://github.com/Harxh-ey/Editflow
The repository contains the complete EditFlow application and its workflow implementation.
How I Built It
EditFlow is built around open-source AI, with Gemma as the primary model for understanding client communication.
The architecture is roughly:
Client conversation
↓
Gemma
↓
Mastra workflow
↓
Requirement extraction
↓
Revision detection
↓
Conflict detection
↓
Tasks + project memory
↓
EditFlow workspace
Gemma
Gemma is used as the intelligence layer that interprets unstructured client communication.
Instead of asking an editor to manually translate a conversation into a project specification, EditFlow uses Gemma to extract structured information from that conversation.
Mastra
Mastra orchestrates the AI workflow and keeps the extraction process organized into explicit steps.
This makes the AI pipeline easier to reason about than simply putting everything behind a single chatbot prompt.
MongoDB Atlas
MongoDB stores project information, requirements, revisions, messages, and workflow results.
An important part of the design is that extracted information retains links back to its source messages.
Sentry
Sentry instrumentation is included to observe failures and workflow behavior, which is particularly important for an AI workflow where model responses can fail or vary.
Render
The application is deployed as a Next.js application on Render.
ElevenLabs
EditFlow also includes an optional voice interaction layer using ElevenLabs for workflows where spoken client feedback is useful.
The Interesting Part: Revision Intelligence
One of the things I wanted EditFlow to understand was that client communication isn't a clean specification.
Clients change their minds.
For example:
Message #2:
"Use clip 12 for the opening."
Message #7:
"Use clip 18 instead of clip 12."
EditFlow doesn't simply overwrite the first requirement.
It records the change:
Clip 12 → Clip 18
The editor can therefore see what changed and why.
The same applies to duration:
Around 60 seconds → Under 30 seconds
Contradiction Detection
EditFlow also tries not to silently resolve ambiguous requirements.
For example, if one message says:
"Keep it around 60 seconds."
and a later message says:
"Actually, make it under 30 seconds."
the system treats this as a meaningful revision.
But when two requirements genuinely don't line up, EditFlow can flag them for clarification rather than pretending it knows what the client intended.
That is an important design principle:
AI should surface uncertainty, not hide it.
Why Does Open Innovation Matter?
A closed AI API could certainly be used to build a similar interface.
But the point of this project was to build the workflow around an open model rather than making the application fundamentally dependent on a proprietary chatbot.
Using Gemma gives the project a model layer that can be adapted to different inference environments and deployment strategies.
That matters for a tool like EditFlow because client conversations can contain sensitive project information.
The architecture therefore keeps the AI provider behind an explicit provider boundary, allowing the inference layer to evolve without rebuilding the entire application.
Open models also make it more realistic to move toward self-hosted inference as the application grows.
Reliability
AI systems don't always return perfectly structured output.
Instead of allowing a model parsing failure to destroy the entire workflow, EditFlow has deterministic fallback extraction.
If the Gemma/Mastra path fails, EditFlow can fall back to its deterministic extraction pipeline and still produce a usable project analysis.
This means the AI layer improves the workflow without becoming a single point of failure.
What I Learned
The biggest lesson from building EditFlow was that the difficult part of an AI application isn't necessarily calling the model.
It's building everything around the model.
You need:
- Structured outputs
- Validation
- Evidence
- Error handling
- Fallbacks
- Workflow orchestration
- Persistence
- Observability
Most importantly, you need to design for the fact that users change their minds.
EditFlow is my attempt to make AI useful for that messy middle ground between a client's words and the work an editor actually has to deliver.
Prize Categories
- Gemma
- Mastra
- MongoDB Atlas
- Sentry
- Render
- ElevenLabs **** <\THANK YOU FOR YOUR TIME/>
Top comments (0)