• 

  logo

About the project

Inspiration

A lot of powerful AI models are technically available, but in practice they are still hard for most people to use. Many of them live behind APIs, inconsistent docs, awkward demos, or workflows that assume you are comfortable writing code and handling raw JSON. I wanted to build something that makes those models easier to reach through a normal UI, without flattening everything into a toy.

My goal was not to abstract away what the models do, but to make them usable by more people. That means giving non-technical users a clear way to run models, upload files, and keep results, while still making the system useful for people who are more technical and want more control.

What it does

FlowHB is a UI for browsing and running many AI models from one place. It gives users a catalog of available models, lets them open a model-specific interface, submit jobs, and review outputs without dealing directly with provider APIs.

It also handles some of the practical parts that usually get ignored in demos: authentication, stored files, saved results, chat sessions, billing/credits, and job tracking. The idea is to make advanced models feel like software someone can actually use repeatedly, not just something they try once in a notebook or playground.

How we built it

I built FlowHB as a React + TypeScript app with Vite on the frontend, and Supabase for authentication, database tables, storage, and edge functions. The frontend gives users a searchable catalog, model run screens, chat interfaces for text models, and pages for tracking jobs and results.

On the backend side, Supabase edge functions handle job submission, job status checks, chat streaming, and billing-related flows. The app connects to multiple model providers, with Gradient featured prominently and other providers handled through the same general UI. A lot of the work was in building a consistent product layer on top of providers that all behave a bit differently.

Challenges we ran into

One challenge was normalizing very different model types into a single product experience. Text models, image generation, video generation, speech, and editing workflows all need different inputs, outputs, and expectations. A single UI can easily become either too generic to be helpful or too custom to scale.

Another challenge was handling the operational side cleanly. Once you move beyond a demo, you need jobs, async status updates, stored outputs, auth, credits, and failure states that users can understand. I also had to think carefully about how to keep the system approachable for non-technical users without making it frustrating for technical users who expect flexibility.

Accomplishments that we're proud of

I am proud that FlowHB is more than a thin wrapper around an API. It already behaves more like a usable product: people can browse models, run them through a consistent interface, save outputs, and come back to previous work.

I am also proud of the balance I am trying to strike. A lot of AI tools either assume a developer audience or over-simplify everything. FlowHB is aiming for a middle ground where the interface is approachable, but the underlying capability is still real.

What we learned

I learned that accessibility in AI tools is not just about nicer design. A lot of the difficulty is structural: different providers expose different schemas, different response formats, different latency patterns, and different failure modes. Making that feel coherent takes a lot more product and systems work than it might seem at first.

I also learned that "easy to use" does not mean "limited." In practice, a good interface needs to help new users get started quickly while still leaving room for more advanced use. That balance is harder than just adding more features or hiding complexity.

What's next for FlowHB

The next step is to keep expanding the model catalog while improving the consistency of the experience across providers and model types. That includes better result management, clearer model metadata, stronger file workflows, and smoother handling of long-running jobs and chat sessions.

I also want to keep integrating more serverless model endpoints so the app can support more providers through the same interface. Gradient is the main focus right now, but the longer-term goal is to make it straightforward to plug in other serverless endpoints as well.

Built With

• bolt
• digitalocean
• react
• supabase