ROEN
What I learned building four applications for the OpenAI ecosystem

What I learned building four applications for the OpenAI ecosystem

By Marian Matinca · · 7 min read
✈

On July 9, 2026, OpenAI launched the new ChatGPT app catalog. On July 21, I had my first application evaluated, approved and published in it — with the other three already in review. Four products, in four domains that have nothing in common: recycling, television, digital safety, travel intelligence. All built by one person, as personal projects, in my spare time.

This article closes the case-study series and answers the question that remains after them: what I learned — and what the four applications, taken together, actually demonstrate.

The whole portfolio, at a glance

Facts first: where software is moving

I don't start from my opinion, but from public numbers. ChatGPT passed 900 million weekly active users — the figure announced officially by OpenAI. On July 9, OpenAI opened the app catalog: a two-sided ecosystem — users get new capabilities with built-in distribution, and developers get a huge market inside a mature ecosystem where 900 million people are already present. Thirteen days after the catalog, on July 22, came OpenAI Presence — the enterprise platform for realtime voice and chat agents, with deployments led by OpenAI's own teams and global integrators (VentureBeat).

Read together, the two announcements tell one story: consumer through the catalog, enterprise through Presence — software is moving to where people already converse. This is more than a trend; it's a platform direction, with investment on both sides of the market. And my opinion — which I mark as opinion — is that the other major players will build their own versions of this model. Assistant-distribution ecosystems are just beginning.

My chronology — and why the order matters

When I started these projects, my goal was not to follow a direction announced by OpenAI. I wanted to understand, through practice, how applications are built that extend a conversational model with real data and services. As I worked, OpenAI began communicating more and more emphatically about exactly the same concepts. I did not claim the convergence — I observed it. And it confirmed I was experimenting in a direction that was becoming ever more relevant.

Dec 2025   RoTV Guide — first commit (a classic TV guide)
Mar 2026   Travel Trends — the European radar begins
Apr 2026   Când Reciclăm — v1 launched publicly
──────────────────────────────────────────────────
Jul  9     OpenAI launches the app catalog
Jul 10     Digital Compass — built on the template, live in a day
Jul 16–17  all 4 applications submitted to review
Jul 21     Când Reciclăm — evaluated, approved, PUBLISHED
Jul 22     OpenAI announces Presence

The order is the argument: three of the four applications existed before the platform did. When the door opened, I didn't start building — I submitted.

Why MCP and not a classic chatbot?

I answered four ways in four studies, but the synthesis is one: a classic chatbot means yet another interface to maintain and users to convince to come to you. MCP inverts the logic — the application goes where users already are. The model brings the conversation and the reasoning; the application brings verifiable data, through tools. And the real stake is trust: a model left on its own will answer fluently and inventedly — the collection schedule, tonight's show, the crisis procedure, the travel conditions. With tools, it doesn't guess: it checks.

The decisions that repeated across all four — the method

The domains have nothing in common. The architecture decisions do — and their repetition is not coincidence, it's method:

  1. One source of truth, four times. The MCP server never has its own database: it reads the same API as the website, the same published data, the same published content, the same radar. Humans and agents see a single truth.
  2. Honesty as architecture, four times. Când Reciclăm says openly which districts publish no data. RoTV exposes its freshness through a public tool. Compass serves only human-written, verified procedures. Travel Trends makes even silence verifiable ("checked, nothing to report" ≠ "didn't check"). For applications built on models that can hallucinate, honesty isn't a moral virtue — it's a design decision.
  3. Narrow tools, with names that say exactly what they do. Tool selection is a product-design problem, not a prompting problem: the right granularity makes the model's choice almost impossible to get wrong.
  4. Read-only, no account, zero personal data — the default rule; the exceptions (a single monitoring tool, in Travel Trends) are explicit and justified.

Four domains, one method. Not four disparate projects — four manifestations of the same competence.

What didn't scale — and what I standardized

Here is the part most presentations skip, but which matters most: I built the first MCP servers differently from one another. Each with its own small decisions, each with its own small mistakes. It didn't scale — every new application would have meant solving the same problems once again.

So I standardized: a single hardened MCP server skeleton, the same rules, the same components — even the visual cards for modern clients were added to all four in the same week. The proof the template works is Digital Compass: built from scratch on the template, live one day after the catalog launched, submitted to review one week after launch — with 270 documents in 9 languages.

That carries the lesson I consider the most valuable of the whole exercise: reproducible speed doesn't come from working more, but from turning every lesson into a template. The first application cost me months. The fourth cost me days.

What I learned about designing for AI agents

What would I do differently today?

Don't take my word for it

Everything I claimed here is verifiable, right now, with one click:

---

Coming next, the final piece of the series: what all of this means for companies and product teams.

✈

Related project

More articles

Open on mmatinca.eu