NextFlow is a web app for building multi-step AI workflows on a visual canvas, the kind of thing you'd use to turn "take this image, crop it, and describe it" or "transcribe this audio and summarize it" into something you can run with one click instead of stitching it together by hand every time. Describe what you want in plain English and NextFlow can generate the whole workflow for you, or start from a blank canvas and wire it up node by node yourself.
I built it to actually understand how automation platforms work under the hood, not from the outside as a user of something like Zapier or n8n, but from the inside: how you model a workflow as a graph, how you run each step reliably in the background, and how you keep a user's canvas in sync with jobs that might take seconds or minutes to finish.
The Problem
Most people who'd benefit from an AI-driven workflow, someone running social campaigns, someone auditing a codebase, someone processing a pile of media, don't want to write a script for it. They want to describe what they need and have something else handle the repetitive execution part. I wanted to build that "something else": a tool where you feed in your data (images, audio, text) once, and the workflow does the rest, every time you run it.
That meant the product had to work at two different levels of comfort. Someone who just wants results should be able to type "describe this image for me" into a text box and get a working workflow back. Someone who wants control should be able to drop onto a blank canvas and build the exact pipeline they have in mind, node by node.
Key Features
- Natural-language workflow generation. A single "What do you want to build today?" input on the dashboard turns a plain-English description into a working workflow, ready to run or edit.
- Prebuilt system templates. The dashboard ships with ready-to-run workflows out of the box, including a social media content pipeline, an image-description auditor, a source-code audit workflow, and an audio/music-identification flow, so there's always a working example to start from or copy.
- A real visual canvas, not a form. Every workflow starts as an Input node and a Response node on a React Flow canvas. The Input node accepts up to ten pieces of media (images, audio) and text fields per workflow, which then feed into whatever processing nodes you build out from there.
- Gemini-powered text nodes. A text node calls Gemini with the data piped in from upstream nodes, plus an optional system prompt, so you can chain things like "describe this image" straight into "turn that description into a caption."
- Media-processing nodes. A crop node takes only image input and lets you crop it directly on the canvas, powered by FFmpeg through Transloadit; audio nodes handle transcription and processing the same way.
- Run the whole thing, or just one node. A workflow can be executed end to end, or a single node can be re-run on its own once its required inputs are available, without re-running everything upstream of it.
- Authenticated, persistent workspaces. Sign in through Clerk lands you on a dashboard of your own workflows and run history, backed by Neon Postgres through Prisma.
Under the Hood
- React Flow renders and manages the workflow canvas itself: nodes, connections, and the live state of what's linked to what.
- Trigger.dev is the actual execution engine. Every node call, whether it's a Gemini request or an FFmpeg crop job, runs as a background job on Trigger.dev's infrastructure rather than blocking the browser, so a slow step in one workflow doesn't freeze the UI or time out.
- Transloadit, with FFmpeg under the hood, handles all media processing: cropping images and transcoding or analyzing audio, so the app itself never has to manage that infrastructure directly.
- Gemini powers every AI text node, taking whatever context is wired into it (an image, a prior node's output, a system prompt) and producing the next step's result.
- Clerk handles authentication end to end, and Prisma on top of Neon (serverless Postgres) stores users, workflows, and run history.
- Zustand manages canvas and workflow state on the client, and Zod validates data moving between nodes and into the backend.
What Went Into Building It
Nothing about this project had one single hard wall to climb, and that was sort of the point. The real work was in getting a lot of different moving pieces, a drag-and-drop canvas, background job orchestration, media processing, and an LLM, to all agree with each other cleanly: a node's output needs to reliably become the next node's input, a long-running background job needs to reflect back onto the canvas correctly, and a crop node needs to refuse to run until it actually has an image to work with. None of it was dramatic on its own. Getting all of it to hold together in both development and production was the actual craft.
Outcomes
- A live, production app where users sign in, build or generate workflows, and run them against real AI and media-processing services.
- Four working system templates covering distinct use cases (social content, image analysis, code auditing, and audio identification) as both onboarding material and proof the underlying engine generalizes.
- A clean separation between the canvas/UI layer and the execution layer (Trigger.dev), meaning the workflow engine itself isn't tied to any one node type and can grow new node kinds without touching how execution works.
