Pe 9 iulie 2026, OpenAI a lansat noul catalog de aplicații din ChatGPT. Pe 21 iulie, aveam prima aplicație evaluată, aprobată și publicată în el — iar celelalte trei erau deja în review. Patru produse, în patru domenii care nu au nimic în comun: reciclare, televiziune, siguranță digitală, travel intelligence. Toate construite de o singură persoană, ca proiecte personale, în timpul liber.
Acest articol închide seria de studii de caz și răspunde la întrebarea care rămâne după ele: ce am învățat — și ce demonstrează, de fapt, cele patru aplicații împreună.
Pe scurt, tot portofoliul
- 4 aplicații live, în 4 domenii diferite — Când Reciclăm, RoTV Guide, Digital Compass, Travel Trends
- 32 de tool-uri MCP publice (5 + 14 + 5 + 8) + 4 tool-uri WebMCP direct în browser
- 1 publicată în catalogul ChatGPT + 3 în review — prima la doar 12 zile după lansarea catalogului
- 4 studii de caz publicate, cu diagrame și numai fapte verificabile, plus pagini „cum funcționează" în 14 versiuni de limbă pe site-urile aplicațiilor
- O singură persoană, timp liber, metodă disciplinată — fiecare afirmație de mai sus e verificabilă cu un click
Întâi faptele: unde se mută software-ul
Nu pornesc de la părerea mea, ci de la cifre publice. ChatGPT a depășit 900 de milioane de utilizatori activi săptămânal — cifra anunțată oficial de OpenAI. Pe 9 iulie, OpenAI a deschis catalogul de aplicații: un ecosistem cu două fețe — utilizatorii primesc capabilități noi cu distribuție integrată, iar dezvoltatorii primesc o piață imensă, într-un ecosistem matur, cu 900 de milioane de oameni deja prezenți. La treisprezece zile după catalog, pe 22 iulie, a urmat OpenAI Presence — platforma enterprise pentru agenți realtime de voce și chat, cu implementări conduse de echipele OpenAI și integratori globali (VentureBeat).
Citite împreună, cele două anunțuri spun o singură poveste: consumer prin catalog, enterprise prin Presence — software-ul se mută în locul unde oamenii deja conversează. Asta e mai mult decât un trend; e o direcție de platformă, cu investiție pe ambele fețe ale pieței. Iar opinia mea — pe care o marchez ca opinie — e că ceilalți jucători mari vor construi propriile versiuni ale acestui model. Ecosistemele de distribuție prin asistenți abia încep.
Cronologia mea — și de ce contează ordinea
Când am început aceste proiecte, scopul meu nu a fost să urmez o direcție anunțată de OpenAI. Am vrut să înțeleg, prin practică, cum se construiesc aplicații care extind un model conversațional cu date și servicii reale. Pe măsură ce lucram, OpenAI a început să comunice tot mai apăsat exact despre aceleași concepte. Convergența nu am revendicat-o — am constatat-o. Și mi-a confirmat că experimentam într-o direcție care devenea tot mai relevantă.
dec 2025 RoTV Guide — primul commit (ghid TV clasic)
mar 2026 Travel Trends — începe radarul european
apr 2026 Când Reciclăm — v1 lansată public
──────────────────────────────────────────────────
9 iul OpenAI lansează catalogul de aplicații
10 iul Digital Compass — construit pe șablon, live într-o zi
16–17 iul toate cele 4 aplicații trimise la review
21 iul Când Reciclăm — evaluată, aprobată, PUBLICATĂ
22 iul OpenAI anunță PresenceOrdinea e argumentul: trei din patru aplicații existau înainte ca platforma să existe. Când s-a deschis ușa, nu am început să construiesc — am trimis.
De ce MCP și nu un chatbot clasic?
Am răspuns în patru feluri, în patru studii, dar sinteza e una: un chatbot clasic înseamnă încă o interfață de întreținut și utilizatori de convins să vină la tine. MCP inversează logica — aplicația merge unde utilizatorii deja sunt. Modelul aduce conversația și raționamentul; aplicația aduce datele verificabile, prin tool-uri. Iar miza reală e încrederea: un model lăsat singur va răspunde fluent și inventat — programul de colectare, emisiunea de diseară, procedura de criză, condițiile de călătorie. Cu tool-uri, nu ghicește: verifică.
Ce decizii s-au repetat în toate patru — metoda
Domeniile n-au nimic în comun. Deciziile de arhitectură, da — și repetiția lor nu e întâmplare, e metodă:
- O singură sursă de adevăr, de patru ori. Serverul MCP nu are niciodată baza lui de date: citește același API ca site-ul, aceleași date publicate, același conținut publicat, același radar. Oamenii și agenții văd un singur adevăr.
- Onestitatea ca arhitectură, de patru ori. Când Reciclăm spune deschis care sectoare nu publică date. RoTV își expune prospețimea printr-un tool public. Compass servește doar proceduri scrise și verificate de om. Travel Trends face verificabilă până și tăcerea („am verificat, nu e nimic" ≠ „nu am verificat"). Pentru aplicații construite pe modele care pot halucina, onestitatea nu e o virtute morală — e o decizie de design.
- Tool-uri înguste, cu nume care spun exact ce fac. Tool selection e o problemă de design de produs, nu de prompt: granularitatea corectă face alegerea modelului aproape imposibil de greșit.
- Read-only, fără cont, zero date personale — regula implicită; excepțiile (o singură unealtă de monitorizare, la Travel Trends) sunt explicite și justificate.
Patru domenii, aceeași metodă. Nu patru proiecte disparate — patru manifestări ale aceleiași competențe.
Ce n-a scalat — și ce am standardizat
Aici e partea pe care majoritatea prezentărilor o sar, dar care contează cel mai mult: primele servere MCP le-am construit diferit unul de altul. Fiecare cu propriile decizii mărunte, fiecare cu propriile greșeli mărunte. Nu scala — fiecare aplicație nouă ar fi însemnat aceleași probleme rezolvate încă o dată.
Așa că am standardizat: un singur schelet securizat de server MCP, aceleași reguli, aceleași componente, până și cardurile vizuale pentru clienții moderni adăugate în toate patru în aceeași săptămână. Dovada că șablonul funcționează e Digital Compass: construit de la zero pe șablon, live la o zi după lansarea catalogului, trimis la review la o săptămână după lansare — cu 270 de documente în 9 limbi.
Asta transmite lecția pe care o consider cea mai valoroasă din tot exercițiul: viteza reproductibilă nu vine din a munci mai mult, ci din a transforma fiecare lecție în șablon. Prima aplicație m-a costat luni. A patra m-a costat zile.
Ce am învățat despre proiectarea pentru agenți AI
- Scrii pentru două audiențe simultan. Fiecare pagină, fiecare structură de date are doi cititori: omul și agentul. Cine proiectează doar pentru unul pierde jumătate din piață.
- Descrierea tool-ului e interfața. Modelul alege tool-ul citindu-i numele și descrierea — ele sunt UX-ul agentic, cu aceeași disciplină pe care o ceri unui buton.
- Prospețimea trebuie să fie verificabilă, nu promisă. Fiecare aplicație are un tool care spune cât de recente sunt datele. Agenții — și oamenii — pot verifica, nu doar spera.
- Review-ul OpenAI e o disciplină, nu un obstacol. Pagini legale, politică de confidențialitate, verificarea domeniului, demo funcțional, aplicație care face ce declară. Cine tratează cerințele astea ca parte din definition-of-done trece repede; prima mea aplicație a fost publicată la 12 zile după lansarea catalogului.
Ce aș face diferit azi?
- Aș începe cu șablonul din prima zi — standardizarea a venit după trei aplicații; putea veni după una.
- Aș trata agent-readiness ca cerință inițială, nu ca retrofit — datele structurate și discovery-ul adăugate ulterior costă mai mult decât cele proiectate de la început.
- Aș scrie studiile de caz din mers — documentarea deciziilor la cald e mai ieftină și mai exactă decât arheologia prin git de după.
Nu mă crede pe cuvânt
Tot ce am afirmat aici e verificabil, acum, cu un click:
- Aplicațiile live: cand-reciclam.madeinro.eu · tv.madeinro.eu · compass.madeinro.eu · travel-trends.mmatinca.eu
- Aplicația publicată în ChatGPT: pagina din catalogul OpenAI
- Codul: Când Reciclăm e open source, pe GitHub
- Studiile de caz: Când Reciclăm · RoTV Guide · Digital Compass · Travel Trends
- Povestea aprobării: AI adoption is a delivery discipline
---
Urmează ultima piesă a seriei: ce înseamnă toate acestea pentru companii și echipele de produs.