Pet project în dezvoltarea aplicațiilor — ce este, idei și de unde să începi

Ce este un pet project și de ce să-l faci

Pet project (din engleză pet project — proiect favorit) — este un produs software pe care programatorul îl creează în timpul liber pentru propriile scopuri: învățare, experimente sau automatizarea sarcinilor personale. Spre deosebire de muncă, unde tehnologiile și arhitectura sunt adesea dictate de afacere și legacy, pet project oferă libertate totală de alegere: vrei să încerci Rust pentru dezvoltare mobilă? Te rog. Vrei să scrii propriul compilator? Înainte.

De ce să faci un pet project? Primul motiv — învățarea prin practică. Teoria (cărți, cursuri, documentație) oferă baza, dar înțelegerea reală vine doar când tu însuți iei decizii arhitecturale, tu însuți repari buguri și tu însuți implementezi în producție. Learning by doing — cel mai eficient mod de a stăpâni un nou stack tehnologic. Al doilea motiv — portofoliu: angajatorul vede nu doar o linie în CV „știu Flutter”, ci un proiect real cu arhitectură, teste și CI/CD.

Al treilea motiv — creșterea carierei. Un programator cu un pet project la interviu poate arăta cod, poate vorbi despre deciziile arhitecturale și poate demonstra înțelegerea ciclului complet de dezvoltare — de la idee la implementare. Conform datelor Stack Overflow Survey (2025), programatorii cu pet projecturi publice primesc în medie cu 15-20% mai multe oferte pentru poziții senior. Pet project — nu o obligație, ci o investiție în carieră.

Cum să alegi o idee pentru pet project

Greșeala principală a începătorilor — să înceapă cu o idee prea mare: „îmi scriu propriul Instagram”. Un pet project cu un domeniu vast este sortit abandonului după 2-3 săptămâni, deoarece programatorul se lovește de complexitate și pierde motivația. Strategia corectă: alege o idee care poate fi adusă la un prototip funcțional în 2-4 săptămâni, apoi extinde iterativ. MVP mindset — versiunea minimă care face exact un lucru.

Cele mai reușite categorii pentru pet projecturi: clona unei aplicații existente pe un stack nou (tracker de obiceiuri, manager de parole, aplicație meteo, cititor RSS); instrument pentru automatizarea unei sarcini personale (parser CV, generator de rapoarte, bot Telegram); bibliotecă sau plugin pentru comunitatea open-source (wrapper comod peste API, plugin Gradle personalizat, plugin Figma). Clone project — cel mai bun start: știi cum ar trebui să funcționeze și te poți concentra pe învățarea tehnologiei, nu pe proiectarea UX.

Criterii de alegere a ideii: te interesează personal (dacă nu e interesant — vei abandona într-o săptămână); realizabil în 2-4 săptămâni până la MVP; permite utilizarea tehnologiei pe care vrei să o înveți; rezolvă o problemă reală (a ta sau a cunoscuților). Idei care nu se potrivesc: încă o listă de sarcini (milion de analogi), schimb de criptomonede (conformitate legală), rețea socială (domeniu vast). Goldilocks principle: nici prea simplu (plictisitor), nici prea dificil (vei abandona), ci unul care este interesant și realizabil.

Alegerea stackului tehnologic pentru proiectul personal

Alegerea stackului depinde de scopul pet projectului. Dacă scopul este învățarea unei tehnologii noi, stackul este evident: exact acea tehnologie. Dacă scopul este crearea unui instrument util, alege stackul în care ești deja competent, pentru a nu pierde timpul învățând sintaxa. Compromise: 70% stack familiar + 30% nou. De exemplu, un programator Android poate lua Kotlin familiar + o arhitectură nouă (MVI în loc de MVVM) și o bibliotecă nouă pentru animații (Compose Animation).

Pentru pet projecturi mobile, combinații populare: Kotlin + Jetpack Compose (Android); Swift + SwiftUI (iOS); Flutter + Dart (cross-platform); React Native + TypeScript (cross-platform). Pentru backend: Kotlin + Ktor (server ușor), Go + Chi (performanță ridicată), Python + FastAPI (prototip rapid). Full-stack pet project poate include client mobil + backend + bază de date + CI/CD — aceasta oferă înțelegerea ciclului complet de dezvoltare.

Sfat important: nu încerca să faci alegerea perfectă a stackului de la început. Alege ceea ce te interesează acum. Dacă după o lună înțelegi că stackul nu se potrivește — rescrie proiectul pe altul. Experiența rescrierii (rewrite) — este și ea o experiență valoroasă. În pet project nu există datorie tehnică în afară de cea pe care ți-o creezi singur. Freedom of choice — principalul avantaj al pet projectului față de dezvoltarea comercială.

Cum să organizezi procesul și să nu abandonezi proiectul

80% dintre pet projecturi sunt abandonate în primele 3 luni. Motivul — nu lipsa timpului, ci organizarea necorespunzătoare. Principalii dușmani: lipsa termenului limită (poți amâna pentru totdeauna), domeniu prea mare (demotivare de la munca infinită), perfecționism (dorința de a face perfect din prima). Anti-patterns: „mai întâi studiez toată documentația, apoi încep să scriu cod” — greșit. Începe să scrii cod din prima zi, folosind documentația ca referință.

Sfaturi practice pentru menținerea impulsului: stabilește un timp regulat pentru proiect (de exemplu, în fiecare marți și joi de la 20:00 la 22:00), fă commituri mici cu mesaje clare (asta dă sentimentul de progres), folosește GitHub Issues sau o simplă listă de sarcini pentru planificarea pașilor următori, implementează devreme (Firebase Hosting, Vercel, GitHub Pages) pentru a vedea rezultatul live. Ship early, ship often — principiul care funcționează și pentru pet projecturi.

Dacă ai sărit o săptămână — nu te învinovăți și nu încerca să recuperezi în weekend. Pur și simplu întoarce-te la programul regulat. Pet projectul nu trebuie să devină o sursă de stres. Dacă proiectul nu mai aduce plăcere — poți să-l amâni sau să-l închizi. Sunsetting (încheierea conștientă a proiectului) — o practică normală. Important este să tragi învățăminte și, poate, să publici codul ca referință.

Cum să transformi pet projectul într-un activ de carieră

Doar să scrii cod și să uiți — nu este suficient. Pentru ca pet projectul să lucreze în favoarea carierei, trebuie să fie prezentabil. Un README de calitate — primul lucru pe care un recrutor sau tech lead îl vede pe GitHub. README ar trebui să conțină: descrierea proiectului (ce și de ce), capturi de ecran sau demonstrație GIF, instrucțiuni de lansare, descrierea arhitecturii (ce modele, biblioteci, abordări), link către un demo live (dacă este cazul). README first impression — cartea de vizită a programatorului.

Elemente suplimentare care cresc valoarea portofoliului: pipeline CI/CD (insigna GitHub Actions în README arată că proiectul este întreținut); teste unitare și UI (demonstrează înțelegerea best practices de testare); documentația arhitecturii (ADR-uri, diagrame); issue-uri și PR-uri cu discuții (arată abilitatea de a lucra în echipă chiar și într-un proiect personal). Quality signals pentru recrutor: teste + CI + README + structură > numărul de stele sau commituri.

Cum să menționezi pet projectul în CV: o secțiune separată „Personal Projects” cu 2-4 proiecte. Pentru fiecare: nume, link GitHub, stack, 2-3 propoziții despre sarcină și soluție. Dacă proiectul are utilizatori activi (prieteni, familie) sau este publicat în magazin — indică neapărat numărul de instalări/descărcări. Metrics: „Pet project pe Flutter, 50+ instalări în Google Play, CI/CD prin GitHub Actions, 85% acoperire cu teste” spune mai mult decât „știu Flutter”.

<!-- Example Personal Projects section in resume -->

## Personal Projects

### BudgetTracker — [GitHub](https://github.com/username/budget)
Stack: Kotlin, Jetpack Compose, Room, Ktor Client
Personal budgeting app with offline-first architecture.
- MVVM + Clean Architecture, 80% test coverage
- Published on Google Play, 200+ installs
- CI/CD via GitHub Actions + Fastlane

### WeatherBot — [GitHub](https://github.com/username/weatherbot)
Stack: Python, FastAPI, Telegram Bot API, Redis
Weather notification bot with location-based forecasts.
- Async processing via Celery + Redis
- Deployed on Railway with 99.9% uptime

Important: nu transforma secțiunea de pet projecturi într-un depozit de 20 de depozite abandonate. Alege 2-3 dintre cele mai bune, unde codul este în ordine, README-ul completat, testele trec. Curated portfolio este mai valoros decât cantitatea.

Când pet projectul devine un proiect open-source

Nu orice pet project trebuie să fie open-source. Dacă proiectul rezolvă o sarcină personală și probabil nu va fi util altora — un depozit privat este perfect ok. Dar dacă proiectul implementează o funcționalitate pe care alți programatori o caută (bibliotecă, plugin, instrument), merită să-l publici public. Open-source adaugă vizibilitate, feedback de la comunitate și construiește reputație în comunitatea de developeri.

Elementele cheie ale unui pet project open-source: licență (MIT, Apache 2.0 — cele mai răspândite); CONTRIBUTING.md (cum să contribui); șabloane de issue (bug report, feature request); code of conduct; versionare semantică cu taguri de release. Fără aceste elemente, proiectul arată ca un experiment personal neterminat, nu ca un proiect open-source. Bariera de intrare: un proiect open-source bun necesită mai mult timp pentru întreținere (revizuirea PR-urilor, răspunsuri la issue-uri) decât pentru scrierea codului.

Povești de succes ale pet projecturilor open-source: Retrofit (Square), Picasso, Coil — toate au început ca pet projecturi ale programatorilor care își rezolvau propria problemă. Picasso (încărcarea imaginilor pentru Android) a fost scris de Jake Wharton într-un weekend ca soluție a unei probleme, iar acum este folosit de milioane de aplicații. Pet to product — drumul de la proiect personal la standard industrial este posibil, dar nu ar trebui să fie un scop în sine.