Inspiration
AI image and video models are becoming incredibly capable, but the creative workflow around them is still fragmented. Creators often jump between different tools, repeatedly upload the same references, translate settings between incompatible model interfaces, and manually organize the results afterward. We built tuziyo because we wanted a single place where the creative context survives: the prompt, reference images, selected model, generation settings, outputs, iterations, and final sequence should all belong to the same project. Our goal was not to build another prompt box. It was to build the workspace around generative models—the part that helps a creator move from an idea to a coherent visual story.
What it does
Creators can select and combine multiple AI models from OpenAI, Google, ByteDance, Kling, and other providers within the same creative project. Each model can contribute its own strengths at different stages of the workflow, while prompts, references, settings, and outputs remain connected in one place.
How we built it
I built tuziyo independently as a solo developer, using OpenAI Codex throughout the entire development process—from product exploration and architecture to implementation, debugging, testing, database migrations, and UI refinement. Tuziyo is an edge-first full-stack application: React 19 and React Router v7 power the server-rendered interface. Cloudflare Workers and Hono provide the API layer. Cloudflare D1 stores users, sessions, generation tasks, outputs, assets, and studio projects. Cloudflare R2 stores reference images and generated media. Asynchronous callbacks, guarded polling, and recovery jobs manage long-running image and video generation. FFmpeg WebAssembly assembles Studio Lite sequences into MP4 files in the browser. Google OAuth handles authentication, while Stripe supports credits and subscriptions. Codex was not just used for isolated coding tasks; it was my development partner throughout the project. I used it to understand and evolve the codebase, evaluate architectural decisions, implement features, design and verify data migrations, trace failures across the frontend and Cloudflare Worker, write tests, and refine the rendered product. This workflow allowed me to build and operate a production-ready application as an independent developer while moving across product design, frontend engineering, backend infrastructure, data modeling, and deployment.
Challenges we ran into
The first challenge was normalizing models without hiding what makes each model useful. Some providers expect reference URLs, while others require Base64 data. One model uses an aspect ratio, another uses a pixel size, and video models introduce duration, start and end frames, resolution, and generated audio. We learned to provide a shared workflow while keeping a capability-driven configuration for every model. The second challenge was making asynchronous generation reliable. A single request can return multiple outputs, complete several minutes later, partially succeed, or fail after the user has left the page. We had to coordinate callbacks, polling, recovery jobs, credits, D1 state, and R2 uploads without creating duplicate or orphaned records. We also had to redesign our data model around outputs instead of assuming that one message always produces one image. Treating every output as its own persistent entity made variant switching, partial failures, deletion, metadata, analytics, and future media types much more robust. Finally, exporting multiple generated video clips in the browser required careful handling of formats, memory, progress reporting, and FFmpeg WebAssembly.
Accomplishments that we're proud of
I’m proud that tuziyo has become a working product rather than a disconnected Build Week demo. A creator can begin with an idea, use the models available in tuziyo to generate images, preserve references and iterations within a session, move successful results into a reusable library, generate video shots, organize those shots into a sequence, and export an MP4—all within one product. I’m particularly proud of the generation pipeline. A single server-side endpoint can create or validate a session and atomically persist its message, task, and expected outputs. Each output has its own status, metadata, storage location, and error state, allowing the interface to accurately represent partial successes and persistent failures. I’m also proud that tuziyo provides a consistent creative workflow across multiple models. Creators can select and combine the models that best fit their project without losing context, results, or creative history.
What I learned
I learned that building the product is only the foundation. A technically complete product does not automatically become a useful or successful one. It also needs promotion, ongoing operations, market validation, and—most importantly—real feedback from users. The product must continue evolving after launch. Observing how people discover tuziyo, where they become confused, which workflows they return to, and why they stop using it is just as important as implementing new features. I also learned to evaluate every product decision from the user’s perspective. The question is not simply whether a feature works, but whether users can understand it, whether it solves a real problem, and whether it makes their creative process easier. Tuziyo will never be “finished.” Its direction should be shaped through continuous conversations with users, real usage data, and repeated cycles of learning, improvement, and validation.
What's next for tuziyo
Next, we want to make tuziyo a complete visual storytelling environment. We plan to add side-by-side model comparison, allowing creators to run the same brief across multiple models, evaluate their strengths, and combine the best results within one project. Studio will evolve from manual sequencing into an AI-assisted production space. Creators will be able to turn a brief into a structured shot list, maintain reusable character and style bibles, generate and compare shot versions, improve visual continuity, and assemble a finished story. Long term, tuziyo should make each model feel like a creative building block—not a workflow boundary.
Log in or sign up for Devpost to join the conversation.