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.
Update, August 14, 2026: RoTV Guide and Digital Compass have also been evaluated, approved and published — three of the four apps are now live in the ChatGPT catalog, with Travel Trends still in review.
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
- 4 live applications, in 4 different domains — Când Reciclăm, RoTV Guide, Digital Compass, Travel Trends
- 32 public MCP tools (5 + 14 + 5 + 8) + 4 WebMCP tools running directly in the browser
- 3 published in the ChatGPT catalog + 1 in review — the first one just 12 days after the catalog launched
- 4 published case studies, with diagrams and verifiable facts only, plus "how it works" product pages in 14 language versions across the apps' websites
- One person, spare time, a disciplined method — every claim above is verifiable with one click
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 PresenceThe 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:
- 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.
- 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.
- 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.
- 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
- You write for two audiences at once. Every page, every data structure has two readers: the human and the agent. Whoever designs for only one loses half the market.
- The tool description is the interface. The model picks a tool by reading its name and description — they are the agentic UX, deserving the same discipline you demand of a button.
- Freshness must be verifiable, not promised. Every application has a tool that says how recent the data is. Agents — and humans — can check, not just hope.
- The OpenAI review is a discipline, not an obstacle. Legal pages, a privacy policy, domain verification, a working demo, an app that does what it declares. Treat those requirements as part of the definition of done and you move fast; my first application was published 12 days after the catalog launched.
What would I do differently today?
- Start with the template from day one — standardization came after three applications; it could have come after one.
- Treat agent-readiness as an initial requirement, not a retrofit — structured data and discovery added later cost more than those designed in from the start.
- Write the case studies as I go — documenting decisions while they're hot is cheaper and more accurate than the git archaeology afterwards.
Don't take my word for it
Everything I claimed here is verifiable, right now, with one click:
- The live applications: cand-reciclam.madeinro.eu · tv.madeinro.eu · compass.madeinro.eu · travel-trends.mmatinca.eu
- The published ChatGPT apps: Când Reciclăm · RoTV Guide · Digital Compass
- The code: Când Reciclăm is open source, on GitHub
- The case studies: Când Reciclăm · RoTV Guide · Digital Compass · Travel Trends
- The approval story: AI adoption is a delivery discipline
---
Coming next, the final piece of the series: what all of this means for companies and product teams.