Actualizare: 5 octombrie 2026

Portofoliul actual prezintă Virality Studio drept spațiu pentru creatori în dezvoltare: redactare, programare, publicare și ajutor AI pentru descrieri. Articolul original Virality Central de mai jos documentează direcția anterioară de antrenament. Gamificarea nu garantează viralitatea unei postări.

Note tehnice originale din mai 2026

Piloții nu învață procedura de pană de motor zburând deasupra unui oraș la oră de vârf. Se prăbușesc de o sută de ori într-un simulator mai întâi, unde singurul lucru pus în joc e orgoliul. Virality Central e aceeași idee, dar îndreptată spre conținut: un loc unde creatorii de social media scriu o postare, primesc un scor AI de viralitate și coaching, apoi iterează de câte ori vor înainte să cheltuie reach real pe ea.

Asta e pariul din spatele produsului. Ce greșesc majoritatea uneltelor de tip „crește-ți audiența" e că presupun că ai deja o audiență pe care să experimentezi. Creatorii noi sau în creștere nu o au. Fiecare postare mediocră pe care o publică e reach pe care nu-l mai recuperează, iar bucla de feedback e lentă și plină de zgomot. Virality Central nu e un scheduler care postează pe Instagram sau TikTok. E un simulator de conținut — exersezi aici, apoi duci ce funcționează în altă parte.

Exersează înainte să riști reach real

Bucla e intenționat simplă. Scrii un draft. Aplicația generează variante de caption și calculează cât de probabil e ca postarea să performeze, apoi dă feedback despre ce trage scorul în jos — hook slab, lipsa unui call to action clar, hashtag-uri care nu se potrivesc cu unghiul. Rescrii. Scorul se mișcă. Nimic din această buclă nu atinge o rețea socială reală, și ăsta e tot rostul: poți greși de cincizeci de ori într-o după-amiază și nu te costă decât timp.

Scoringul rulează prin OpenRouter către Gemini 2.0 Flash. Am ales Flash pentru că bucla trebuie să fie ieftină și rapidă — un creator care iterează pe un caption va lovi scorerul de zeci de ori într-o sesiune, iar un model lent sau scump ar omorî ritmul. Există și un fallback local de generare caption, ca funcția să se degradeze elegant în loc să cadă complet când API-ul upstream are un hop, sau când o cheie rămâne fără credit. A trata LLM-ul ca pe un singur provider interschimbabil în spatele unei abstracțiuni, în loc să bag apelurile Gemini direct în view-uri, e un pattern pe care îl folosesc în mai multe proiecte și despre care scriu mai pe larg în workflow-ul meu de dezvoltare solo asistat de AI.

Motorul de gamification

O unealtă de scoring, singură, e un calculator. Ce-i face pe oameni să revină e stratul de joc construit în jurul ei, și aici stă, de fapt, cea mai mare parte din complexitatea backendului.

Mecanica principală e clout index — un singur număr care reprezintă statutul unui creator pe platformă, recalculat orar de un job de fundal, nu la fiecare request. Decizia asta contează mai mult decât pare. Recalcularea unui scor compozit inline, la fiecare încărcare de pagină, ar fi și lentă, și ușor de păcălit; rularea în batch, pe un program, ține leaderboardul stabil și matematica cinstită, cu prețul ca numărul să fie ușor învechit între rulări. Pentru o metrică de statut, ușor învechit e compromisul corect.

În jurul lui stă schela obișnuită de progresie, construită ca lumea, nu falsificată:

  • XP și niveluri care deblochează funcții pe măsură ce urci
  • Streak-uri care răsplătesc prezența zilnică
  • Achievement-uri și misiuni pentru comportamente specifice
  • Skill tree-uri pentru competențe distincte de creator — captioning, strategie, pitch pentru brand deals
  • Provocări săptămânale și un leaderboard

Există și un sistem complet de postări în interiorul simulatorului — drafturi, comentarii, like-uri, bookmark-uri, un feed de explore — plus competiții cu înscrieri și vot, analytics cu snapshot-uri zilnice și un Creator Academy cu cursuri, lecții și quiz-uri. „Publicarea" programată în aplicație rulează pe un job Celery beat la fiecare cinci minute. Ca să fie clar la nivel de scope: acel scheduling trăiește în întregime în feedul propriu al Virality Central. E parte din simulare, nu o punte către platforme reale.

Stack-ul

Împărțirea de aici e partea cea mai cu personalitate din build și partea pe care aș apăra-o cel mai dârz: un frontend generat peste un backend construit de mână.

Frontendul a fost schelăuit cu Lovable — Vite, React 18, TypeScript, shadcn/ui pe Radix, Tailwind, TanStack Query și react-router. Scaffoldingul cu AI e chiar bun la stratul ăsta acum. Arborele de componente, routingul, hook-urile de query — teren bătătorit, unde codul generat te duce rapid la un UI funcțional, și sunt bucuros să las o unealtă să-l facă.

Backendul e exact pe dos. E Django 5.1 cu Django REST Framework, construit de mână în opt aplicații, și l-am scris deliberat fiindcă acolo stau deciziile care chiar contează:

  • Auth pe JWT pentru acces stateless la API dinspre SPA.
  • camelCase pe sârmă. Django vorbește snake_case intern; frontendul React așteaptă camelCase. În loc să umplu vreuna dintre părți cu traduceri, API-ul serializează spre camelCase la graniță, așa că frontendul consumă JavaScript idiomatic, iar backendul rămâne Python idiomatic.
  • Tiere de throttling pe endpointurile DRF, care contează mult când fiecare interacțiune se poate ramifica într-un apel LLM plătit.

Datele și infra sunt PostgreSQL și Redis, cu Celery și Beat care duc munca programată — recalcularea orară a clout-ului, jobul de publish la cinci minute. E containerizat cu Docker Compose în spatele Traefik și nginx, deployat prin Coolify. În jur de cincizeci de endpointuri de API sunt cablate în cele opt aplicații.

O notă despre nume

Dacă te uiți cu atenție, dai de o mică personalitate dublă. Produsul e Virality Central la viralitycentral.com, dar intern — în repo, în configuri, în jumătate din notițele mele — e încă Virality Studio. Driftul ăsta e genul de lucru care se întâmplă când numele se stabilește după ce codul e deja scris, iar redenumirea tuturor lucrurilor pe interior e o corvoadă care nu ajunge niciodată în capul listei. Îl las așa, ca pe un artefact cinstit despre cum a fost de fapt construit produsul.

Unde e acum și ce urmează

Status: live/MVP. Planul de producție îl are deployat pe viralitycentral.com pe un PostgreSQL partajat, cu configurile de producție nginx și Docker și mediul de prod, toate la locul lor. L-aș numi live, dar tânăr.

Avertismentele cinstite:

  • Acoperirea cu teste e subțire. Testele acoperă 2 din cele 8 aplicații. Căile de gamification și de scoring AI — părțile cele mai riscante și mai dense în logică — nu sunt încă acolo unde le-aș vrea.
  • Empty-state-urile sunt în lucru. Am scos recent mock data care făcea ecranele de început să pară populate, ceea ce a scos la iveală un lot de gestionare de empty-state încă în curățare. Un cont nou-nouț vede în acest moment mai multe panouri goale decât ar trebui.
  • Modelul de business e nedecis. Landing page-ul spune „free forever", dar nu există cod de billing în spate, așa că tratează-l ca pe un placeholder, nu ca pe o promisiune.

Un lucru pe care în mod explicit nu-l repet: landing page-ul arată cifre mari de creatori și postări și un rating aproape perfect. Acelea sunt placeholdere de marketing hardcodate, cu avatare de stock, nu numere reale, și nu le voi împopoțona aici ca tracțiune. Starea cinstită e „bucla de simulator funcționează, stratul de joc e construit, iar acum are nevoie de creatori reali care să bage drafturi reale prin el".

Dacă framingul „exersează înainte să riști" îți rezonează, același instinct — construiește de mână backendul plictisitor și portant, și lasă AI-ul pe scaffolding — străbate tot ce e în portofoliul de produse pe care le construiesc solo. Poți vedea restul a ce livrez pe pagina de proiecte.

djangoopenroutergeminigamificationdrflovable
Distribuie articolul