Using OSS models to build AI apps with millions of users

How do you turn an AI app idea into a finished product—and get people to use it? Hassan El Mghari approaches that problem through repeated, small launches. At the time of the talk, he reports averaging one app a month over four years. He publishes the code so other developers can inspect the implementation, learn from it, and contribute.

The model infrastructure behind these projects is Together AI, where El Mghari says he leads developer relations. Its inference API spans chat models such as Qwen3, reasoning models such as DeepSeek-R1, and image models such as Flux Kontext, alongside vision and audio models. Dedicated instances, fine-tuning on your own data, and GPU training clusters are separate options beyond querying a hosted model.

Two changes make these experiments easier to attempt. Cursor and Windsurf help with coding; Bolt, v0, and Lovable accelerate prototypes. Chat tools can also help a developer brainstorm or navigate an unfamiliar workflow, such as building a first Swift app. Meanwhile, new models enable new kinds of applications. Development assistance reduces the work of building, while model improvements expand what is worth building.

That opportunity does not make demand predictable. El Mghari describes a portfolio ranging from apps used by a few thousand people to apps used by more than a million. Repeated experiments matter because the same builder and similar infrastructure can produce very different adoption outcomes.

An early way to find ideas was to search Twitter for people describing software they wanted. One request asked for an AI app to help choose glasses. The resulting tool collected shopping requirements, converted them into a query, and used the Amazon API to find products with links people could actually buy from. The useful output was a path to a purchase, grounded in available products.

A request from his friend Theo led to an equally narrow developer tool: generate commit messages. After the developer stages changes with git add, the tool sends the Git diff to a model, displays a proposed message, and lets the developer accept it. Staging supplies the changes; it should not be confused with invoking the model. The generated message remains a proposal until the user accepts it. El Mghari estimates about 40,000 installations or downloads for the open-source commit-message tool.

Contributors subsequently helped improve that project. Publishing the source therefore served a second purpose beyond distribution: other developers could participate in maintaining and extending a small application.

LlamaCoder expands the transformation from a commit message to a small application. The example prompt asks for an American-history quiz. In the pipeline El Mghari describes, one model turns that request into a project plan; another uses the plan to write React code for display. Planning and code generation are distinct operations. For LlamaCoder, he reports about five million requests, one million apps generated, and a little over one million users. Requests, generated apps, and users are separate measures, not interchangeable counts.

BlinkShot generates images as the user proceeds through the experience. For BlinkShot, he reports over one million users and about 48 million generated images. Napkins uses a different input: an image of a hand-drawn web-app sketch becomes an application. He reports about 40,000 users for Napkins. These are his reported adoption figures, rather than independently established analytics totals.

Another app accepts a resume and produces a personal website. The displayed page pairs an Upload Resume button with a profile preview containing About, Work Experience, and Education sections. It makes the input and intended output visible together.

The remaining examples include menu visualization, a tutor that explains a requested topic—personal finance in the example—at an elementary-school level, and OCR tools. Each gives the model a bounded job with an output the user can recognize immediately.

Most of these apps share a straightforward sequence:

1. Accept text or an uploaded image.
2. Send that input to a model, commonly through Together AI.
3. Often store the generated text or image so it can be shown again.
4. Display the result to the user.

For an image-to-image app, that means accepting an image, requesting a transformed image, optionally persisting it, and presenting it. Many of El Mghari’s apps need only one model API call. A small inference workflow makes the idea faster to build and faster to validate. The earlier planning-plus-code-generation example shows that this is a common pattern, not a rule that every app must fit.

His usual stack assigns familiar services to the surrounding application work:

The model call sits inside an ordinary web application with storage, identity, styling, and measurement.

Plausible exposes unique visitors, referral sources, countries, and devices. The device breakdown repeatedly surprises El Mghari: many people use his apps on mobile, making the phone experience a practical priority. Helicone provides a different view—inspection of LLM requests for troubleshooting—while Vercel hosts the applications. These are the stack choices described in the recording; linked repositories may now contain later implementation choices.

The process starts before implementation: keep a running list of ideas. Record them when they occur, including interesting products whose method could apply to another problem. El Mghari maintains a shortlist of roughly five apps he wants to build next. The list gives him a direction without preventing a timely experiment: a compelling new open-source image model can move ahead of the existing queue.

Once an idea is selected, narrow it into a working flow:

1. Name it. Choose a short, memorable name and check domain availability; DomainsGPT is one tool he suggests.
2. Design the screens. Work through the landing page, the input or upload step, and the result. Use paper, Figma, or a prototyping tool to make the transitions concrete.
3. Build the smallest working version. Aim for a complete experience with as little backend machinery as possible, often a single API endpoint.

The purpose of the sketch is to settle what the user does and sees before expanding the implementation.

With a working prototype, the next decisions concern cost and access. How expensive is each use? How many uses should each person receive per day? Should the app require authentication or support a bring-your-own API key option? Those choices depend on the application and the model it calls.

Launch preparation includes an Open Graph (OG) preview image, a domain, analytics, and a clear README. Because the projects are open source, the code should be easy to understand and clone. Then comes the public announcement, usually on LinkedIn or X, followed by watching responses and monitoring bugs. The launch slide places access limits, repository preparation, and announcement in that order.

A useful scope test is whether you can describe the app in roughly five words. BlinkShot generates images in real time; LlamaCoder turns text into an app. Contrast that with a personal CRM that accumulates a dashboard, weekly emails, and numerous other features before anyone tries it. An exciting idea can still be small enough to test before months of work make it costly to abandon.

A simple model workflow can still deserve substantial interface work. El Mghari says he spends 80% of development time on the UI for most of his apps. He recalls early projects whose poor appearance discouraged use, then describes a polished PDF-summary app that attracted tens of thousands of users even though ChatGPT could already perform the underlying task. In his experience, appearance, ease of use, and a straightforward flow helped the dedicated app find an audience; this is an account of his projects, not a controlled comparison.

Keeping most apps to one or two API calls also makes it easier to build around newly available capabilities. BlinkShot used Flux Schnell, and El Mghari recalls launching it about two days after the model appeared. A fast image model made a real-time generation experience possible, while arriving early increased the app’s potential to be shared.

Even after roughly 40 apps, he says he cannot reliably predict which will succeed. A week-sized experiment limits the cost of discovering weak demand compared with a project that consumes six months before feedback. Launch early, then use the response to decide whether to iterate or move on.

Free access and open-source code help people learn from an app and give them reasons to share it. Continued shipping supplies another kind of return even when individual launches attract little attention: practice improves implementation speed, idea selection, and the builder’s understanding of what resonates.

The audience first asks why this traction has not led El Mghari to start a company. His answer puts the adoption numbers in context: teaching and experimentation are central goals, and he attributes part of the apps’ success to keeping them free and open source. Sponsors support that choice, while videos and blog posts extend the educational value. He leaves open the possibility of a future company around an idea he particularly enjoys, but monetization is not the current objective.

Asked what has surprised him about demand, he identifies one recurring pattern: apps perform better in his experience when users can easily share what they create. For an image generator, sharing should be easy and the shared link should have an appealing OG preview. A friend sees the output, visits the app, tries it, and can share another creation. The output itself becomes an entry point for the next user.

Free access still has infrastructure costs. In response to a question about who pays, El Mghari says Together AI sponsors the model compute, Neon provides a free database, and Clerk provides an authentication account. The providers gain exposure through reusable open-source projects that introduce developers to their services. He recommends launching an open-source app and asking relevant providers for credits, based on his own success doing so; support is not guaranteed.

The final question concerns maintaining a growing portfolio while models change quickly. El Mghari treats model replacement as an opportunity: a better model arriving months later can improve an existing app or enable something it could not previously do. In his experience, the change is often as small as updating a model selection in one line—not a guarantee that every model is interchangeable. He revisits apps, replaces models, sometimes adds a small feature, and relaunches them. A finished application can therefore benefit from later model progress without requiring an entirely new product.