Hassan El Mghari builds open-source AI apps by reducing each idea to a simple workflow, often with one API call.
2
A polished user interface, an early launch, and an easy way to share generated work have mattered more than adding many features.
3
He keeps shipping because he cannot predict which ideas will spread, and each small launch teaches him what users want.
Summary
Hassan El Mghari explains how he builds open-source AI applications, from an idea to a working product with a large audience. His examples include tools for generating images, building apps, creating websites from resumes, and writing Git commit messages. Most follow a simple pattern: accept text or an image, call an open-source model, save the result when needed, and show it to the user. He uses Together AI, Next.js, TypeScript, Neon, Clerk, Prisma, Tailwind, S3, Plausible, Helicone, and Vercel. His process starts with a running list of ideas, then covers naming, rough design, a minimal prototype, usage limits, launch preparation, and public release. He spends much of his time on interface design and launches early to avoid spending months on an idea that does not work. He also looks for new models and builds sharing into the product. Sponsorships and open-source partnerships cover much of his infrastructure cost.
Open-source apps can reach large audiences through repeated small launches
Hassan El Mghari has built AI applications for about four years, averaging roughly one app per month. Everything he makes is open source, so people can inspect the code and contribute. The results vary widely. Some projects reach only a few thousand users, while others reach more than a million. His text-to-app builder has handled about 5 million requests, produced about a million apps, and reached a little over a million users. An image-generation app has produced about 48 million images and also reached more than a million people. He treats this spread as a numbers game, which means trying many ideas instead of expecting every project to succeed.
Lower building costs and better models make experimentation easier
Hassan says the barrier to building has dropped sharply. Tools such as Cursor and Windsurf can autocomplete code inside an IDE. Bolt, v0, and Lovable can help prototype an application quickly. Chat applications can guide someone through an unfamiliar task, such as building a Swift app. At the same time, new models arrive frequently and enable applications that were previously difficult to make. This combination lets a solo builder move from an idea to a working experiment faster. He presents the current moment as a good time to build because both the software-development process and the underlying model capabilities have improved.
Most of his applications use a short input-to-output pipeline
The architecture behind many of Hassan's applications is deliberately small. A user types something or uploads an image. The application sends that input to an AI model on Together AI. It may store the resulting text or image in a database, then displays the result to the user. Often there is only one API call between the user action and the response. Hassan says this simplicity helps him move quickly and validate an idea before adding more machinery. His examples include image-to-image tools, app generators, and other products where the model call is the central operation.
A practical stack handles the application around the model
Hassan uses Together AI for model access and Next.js with TypeScript as his full-stack framework. Neon provides a serverless Postgres database, Clerk handles authentication, and Prisma connects the application to the database. He uses Shadcn and Tailwind for styling, S3 for image uploads, Plausible for website analytics, Helicone for inspecting and troubleshooting language-model requests, and Vercel for hosting. Plausible lets him see visitors' countries and devices. He was surprised by how many people use his applications on mobile, so he treats the mobile experience as an important part of the product rather than an afterthought.
A running idea list turns random inspiration into a build queue
Hassan keeps a continuing list of application ideas because people often have useful ideas and then fail to record them. He maintains a shortlist of about five projects he wants to build next. A new model can change that order. If an impressive open-source image model appears, he may move quickly to build an application around it. He also spends time choosing a short, memorable name and checking whether a suitable domain is available. For the initial design, he thinks through the screens and user flow on paper, in Figma, or with a prototyping tool before writing the application.
The first version should be a very small working product
Hassan tries to build the simplest working version of a specific idea, often aiming for one API endpoint. Once the prototype works, he considers authentication, usage limits, cost, and whether users should bring their own API key. Those choices depend on the application and the model it uses. Before launch, he prepares an image for social previews, registers a domain, adds analytics, and writes a README that makes the open-source code easy to clone. He then launches on LinkedIn or X and watches how people respond. This process keeps product decisions tied to actual use instead of a long speculative build.
Good interface design can matter more than the novelty of the model
Hassan says he spends about 80% of his time on the user interface for many of his applications. Earlier projects looked bad, and he believes that contributed to their lack of use. A simple PDF summarizer can still attract users if it is easy to understand and looks polished. He reports that tens of thousands of people used his PDF summary application after he invested in its presentation. He also advises describing the idea in five words, with examples such as Blinkshot, "generate real-time images," and LlamaCoder, "go from some text to an app." A narrow product is easier to build and test than a large feature list.
Fast launches and shareable results make uncertainty affordable
Hassan recommends using current models when they create a clear opportunity. He launched Blinkshot two days after the Flux Schnell model appeared, making the application an early use of that fast model. He also launches before he knows whether an idea will work. After roughly 40 apps, he still cannot reliably predict which ones will succeed, so a week-long experiment limits the cost of being wrong compared with a six-month project. In a question-and-answer session, he adds that applications do better when users can easily share what they create. He now tries to make generated images and their social preview images easy to pass to friends.
"For a lot of these apps, like still to this day, you know, like 40 apps later, I still have no idea what will do really, really well versus what won't."13:16
Who should watch
You want to ship a small AI product but are stuck choosing an idea or designing the first version.
Your prototype works, but you need practical guidance on interfaces, usage limits, analytics, hosting, and launch preparation.
You are interested in open-source projects and want to fund model calls and infrastructure through company sponsorships or credits.
