Flowrabbit Studio

The Architectural Premise: Unifying UI and Orchestration

When we started Flowrabbit, we had a clear idea: most AI workflow tools separate the orchestration backend from the interface people actually use. We thought there was a better way.

Design the UI, model the workflow, and keep human review in the exact same visual environment.

When an AI application is more than just a simple chain of model calls, inputs, generated content, and branching states all need a visible place in the product. Keeping those concerns together lets a builder reason about what the end-user sees at the exact same time as what the workflow does.

We built a highly specialized technical core:

• Shared Visual Model: The infinite canvas represented both UI interface components (text inputs, buttons, tables) and workflow nodes (LLM wrappers, API connectors) through explicit data bindings. You could literally draw a line from an API output node directly into a UI text field.
• Human-in-the-Loop as a Native Node: We recognized that AI cannot be trusted blindly in enterprise workflows. Human review was treated as a primary execution node. A workflow could execute, pause at an approval gate, wait for a user's input on the canvas, and then safely resume execution without hiding the state in an external background process.
• Reproducible Self-Hosting: AI workflows handle sensitive data, so deployment had to remain under the team's control. We containerized the services—separating the visual editor, execution backend, persistence layer, and secrets management—allowing for a seamless Docker-based self-hosted deployment.

The Reality Check: The Visual Programming Problem

We set out to allow anyone to create AI apps visually by dragging nodes and connectors onto the canvas and wiring them to visual elements. The architecture worked beautifully. The product experience, however, did not.

As we put Flowrabbit into the hands of users, we collided with a harsh reality of visual programming: in our attempt to democratize AI app creation, our approach inadvertently added more resistance than ease of use.

We fell into a classic product trap:

• For a designer, reasoning about API payloads, data bindings, and execution states on a canvas was overwhelming.
• For a developer, manually wiring visual nodes felt like a slow, frustrating constraint compared to just writing code.

The system was too technical for non-technical users and far too restrictive for real software developers.

Neither of our target audiences were happy. And when your product doesn't fully satisfy anyone, that's a fundamental product problem.

The Seismic Shift: When the World Changed

Then the industry shifted again.

The arrival of "vibe coding"—the ability to generate complete applications simply by describing them in plain text to AI-assisted IDEs—fundamentally changed how software is built.

Tools like Cursor, Vercel's v0, and other AI code assistants proved something important: writing a prompt to generate a UI is a vastly superior developer experience to manually wiring visual nodes.

We weren't wrong in our technical assumptions. Our mistake was not seeing that the market was moving. We were caught between two technological eras.

The Decision: Go Open Source

Recognizing this massive shift in the UX paradigm, we made a decision. We weren't going to try to compete in a world where "vibe coding" had already won. Instead, we opened everything up.

Today, Flowrabbit is fully open-source on GitHub.

It's not a "project graveyard" where code dies silently. It stands as a highly robust, self-hostable foundation for AI orchestration, infinite-canvas rendering, and human-in-the-loop logic. Many of the technical leadership patterns and orchestration designs I built for Flowrabbit became the practical foundation for other complex AI systems I've architected since.

The important part: the work wasn't wasted. We learned deep architectural lessons that inform every system we build now.

What We Learned: Architecture Can't Overcome Market Shifts

Here's what's useful about any startup journey: what the work teaches you.

Flowrabbit taught us three crucial things:

1. Visual builders only feel simple when the underlying contracts are precise. Components, data bindings, branching, secrets—all need clear boundaries. If they don't, the canvas becomes chaotic as the application grows.

2. An elegant architecture cannot overcome a fundamental shift in user behavior. We spent years polishing the architecture. We built something technically beautiful. But it didn't matter when the industry moved toward "vibe coding".

3. Sometimes accepting a loss is the smartest decision. Converting Flowrabbit to open-source was an act of honesty. We recognized we weren't the right path forward, so we put it where it could serve as a foundation for others.

What's Next: Text-to-UI and the Future

Flowrabbit isn't dead. It's evolving.

Now that the project is open-source, we are actively analyzing how to integrate Text-to-UI generation directly into the platform. By bridging our robust visual workflow runtime with modern generative coding practices, we aim to finally solve the friction that held the original vision back.

The visual canvas remains a powerful abstraction for complex orchestration. But the way people interact with it probably won't be dragging nodes. It'll be describing what they want in natural language, and letting AI generate the visual canvas.

It's a different journey. But it's not a finished one.