Pet project az alkalmazásfejlesztésben — mi ez, ötletek és honnan kezdjük

Mi az a pet project és miért érdemes csinálni

Pet project (angolul pet project — kedvenc projekt) — egy szoftvertermék, amelyet a fejlesztő szabadidejében hoz létre saját céljaira: tanulásra, kísérletezésre vagy személyes feladatok automatizálására. A munkától eltérően, ahol a technológiákat és az architektúrát gyakran az üzlet és a legacy diktálja, a pet project teljes választási szabadságot ad: ki akarod próbálni a Rust-ot mobilfejlesztéshez? Tessék. Meg akarod írni a saját fordrítóprogramodat? Rajta.

Miért érdemes pet projectet csinálni? Az első ok — tanulás gyakorlás által. Az elmélet (könyvek, tanfolyamok, dokumentáció) alapot ad, de a valódi megértés csak akkor jön el, amikor te magad hozol architektúrális döntéseket, te magad javítod a hibákat és te magad telepítesz éles környezetbe. Learning by doing — a leghatékonyabb mód egy új technológiai stack elsajátítására. A második ok — portfólió: a munkaadó nem csak egy sort lát az önéletrajzban „ismertem Fluttert”, hanem egy valódi projektet architektúrával, tesztekkel és CI/CD-vel.

A harmadik ok — karrier előrelépés. A pet projecttel rendelkező fejlesztő az interjún meg tudja mutatni a kódot, beszélni tud az architektúrális döntésekről és demonstrálni tudja a teljes fejlesztési ciklus megértését — az ötlettől a telepítésig. A Stack Overflow Survey (2025) adatai szerint a nyilvános pet projectekkel rendelkező fejlesztők átlagosan 15-20%-kal több ajánlatot kapnak senior pozíciókra. Pet project — nem kötelezettség, hanem befektetés a karrierbe.

Hogyan válassz ötletet pet projecthez

A kezdők fő hibája — túl nagy ötlettel kezdeni: „megírom a saját Instagramomat”. A nagy hatókörű pet project 2-3 hét után elhagyásra van ítélve, mert a fejlesztő komplexitásba ütközik és elveszti a motivációt. A helyes stratégia: olyan ötletet válassz, amelyet 2-4 hét alatt működő prototípussá lehet fejleszteni, majd iteratívan bővíteni. MVP mindset — a minimális verzió, ami pontosan egy dolgot csinál.

A legsikeresebb kategóriák pet projectekhez: meglévő alkalmazás klónja új stacken (szokáskövető, jelszókezelő, időjárás alkalmazás, RSS olvasó); eszköz személyes feladat automatizálására (önéletrajz elemző, jelentésgenerátor, Telegram bot); könyvtár vagy plugin nyílt forráskódú közösség számára (praktikus wrapper API-hoz, egyedi Gradle plugin, Figma plugin). Clone project — a legjobb kezdet: tudod, hogyan kell működnie, és a technológia tanulására összpontosíthatsz, nem az UX tervezésére.

Az ötletválasztás szempontjai: személyesen érdekel (ha nem érdekes — egy hét alatt feladod); megvalósítható 2-4 hét alatt MVP-ig; lehetővé teszi a technológia használatát, amit meg akarsz tanulni; valós problémát old meg (a tiédet vagy ismerőseidét). Nem megfelelő ötletek: még egy feladatlista (millió analóg), kriptotőzsde (jogi megfelelés), közösségi hálózat (hatalmas hatókör). Goldilocks principle: ne túl egyszerű (unalmas), ne túl bonyolult (feladod), hanem pont érdekes és elérhető.

Technológiai stack választása személyes projekthez

A stack választása a pet project céljától függ. Ha a cél egy új technológia megtanulása, a stack egyértelmű: pont az a technológia. Ha a cél egy hasznos eszköz létrehozása, válassz olyan stacket, amelyben már kompetens vagy, hogy ne veszíts időt a szintaxis tanulásával. Compromise: 70% ismert stack + 30% új. Például egy Android fejlesztő vehet ismert Kotlin + új architektúrát (MVI az MVVM helyett) és új animációs könyvtárat (Compose Animation).

Mobil pet projectekhez népszerű kombinációk: Kotlin + Jetpack Compose (Android); Swift + SwiftUI (iOS); Flutter + Dart (cross-platform); React Native + TypeScript (cross-platform). Backendhez: Kotlin + Ktor (könnyű szerver), Go + Chi (magas teljesítmény), Python + FastAPI (gyors prototípus). Full-stack pet project tartalmazhat mobil klienst + backendet + adatbázist + CI/CD-t — ez megadja a teljes fejlesztési ciklus megértését.

Fontos tanács: ne próbálj tökéletes stack választást csinálni a kezdetekkor. Válaszd azt, ami most érdekel. Ha egy hónap után rájössz, hogy a stack nem megfelelő — írd át a projektet másikra. Az átírás tapasztalata (rewrite) — szintén értékes tapasztalat. A pet projectben nincs technikai adósság azon kívül, amit magadnak teremtesz. Freedom of choice — a pet project fő előnye a kereskedelmi fejlesztéssel szemben.

Hogyan szervezd meg a folyamatot és ne hagyd abba a projektet

A pet projectek 80%-át az első 3 hónapban abbahagyják. Az ok — nem időhiány, hanem rossz szervezés. A fő ellenségek: határidő hiánya (örökre elhalasztható), túl nagy hatókör (demotiváció a végtelen munkától), perfekcionizmus (a vágy, hogy elsőre tökéletes legyen). Anti-patterns: „először áttanulmányozom az összes dokumentációt, aztán elkezdek kódot írni” — rossz. Kezdj el kódot írni az első naptól, a dokumentációt használd kézikönyvként.

Gyakorlati tanácsok a lendület fenntartásához: állíts be rendszeres időt a projektre (például minden kedden és csütörtökön 20:00-tól 22:00-ig), készíts kis commitokat érthető üzenetekkel (ez előrehaladás érzetét adja), használd a GitHub Issues-t vagy egy egyszerű feladatlistát a következő lépések tervezéséhez, telepíts korai fázisban (Firebase Hosting, Vercel, GitHub Pages), hogy élőben lásd a munka eredményét. Ship early, ship often — ez az elv pet projectekre is működik.

Ha kihagytál egy hetet — ne hibáztasd magad és ne próbáld bepótolni a hétvégén. Egyszerűen térj vissza a rendszeres útemezéshez. A pet project nem válhat stresszforrássá. Ha a projekt már nem okoz örömet — elhalaszthatod vagy bezárhatod. Sunsetting (a projekt tudatos befejezése) — normális gyakorlat. A fontos, hogy tanulj a tapasztalatokból, és esetleg publikáld a kódot referenciaként.

Hogyan változtasd a pet projectet karrier előnnyé

Csak megírni a kódot és elfelejteni — nem elég. Ahhoz, hogy a pet project a karrieredet segítse, prezentálhatónak kell lennie. Egy minőségi README — az első dolog, amit a toborzó vagy tech lead lát a GitHubon. A README-nek tartalmaznia kell: a projekt leírását (mit és miért), képernyőképeket vagy GIF bemutatót, indítási útmutatót, architektúra leírást (milyen minták, könyvtárak, megközelítések), linket az élù demóhoz (ha van). README first impression — a fejlesztő névjegykártyája.

További elemek, amelyek növelik a portfólió értékét: CI/CD pipeline (a GitHub Actions jelvény a README-ben mutatja, hogy a projekt karban van tartva); egység- és UI tesztek (bemutatják a tesztelési best practices megértését); architektúra dokumentáció (ADR-ek, diagramok); issue-k és PR-ek megbeszélésekkel (mutatják a csapatmunka képességét még személyes projektben is). Quality signals a toborzó számára: tesztek + CI + README + struktúra > csillagok vagy commitok száma.

Hogyan említsd meg a pet projectet az önéletrajzban: külön „Personal Projects” szekció 2-4 projekttel. Mindegyikhez: név, GitHub link, stack, 2-3 mondat a feladatról és megoldásról. Ha a projektnek vannak aktív felhasználói (barátok, család) vagy meg van jelentetve áruházban — mindenképp add meg a telepítések/letöltések számát. Metrics: „Pet project Flutterben, 50+ telepítés a Google Play-en, CI/CD GitHub Actions segítségével, 85% teszt lefedettség” többet mond, mint „ismertem Fluttert”.

<!-- 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

Fontos: ne változtasd a pet projectek szekciót 20 elhagyott repository szeméttelepévé. Válassz 2-3 legjobbat, ahol a kód rendben van, a README kitöltve, a tesztek mennek. Curated portfolio értékesebb, mint a mennyiség.

Mikor válik a pet project open-source projektté

Nem minden pet projectnek kell open-source-nak lennie. Ha a projekt a személyes feladatodat oldja meg és valószínűleg nem lesz hasznos mások számára — a privát repository tökéletesen megfelel. De ha a projekt olyan funkcionalitást valósít meg, amit más fejlesztők keresnek (könyvtár, plugin, eszköz), érdemes nyilvánosan publikálni. Open-source növeli a láthatóságot, visszajelzést ad a közösségtől és építi a hírnevet a fejlesztői közösségben.

Az open-source pet project fő elemei: licenc (MIT, Apache 2.0 — a legelterjedtebb); CONTRIBUTING.md (hogyan lehet hozzájárulni); issue sablonok (hibabejelentés, funkciókérés); code of conduct; szemantikus verziókezelés kiadási címkékkel. Ezen elemek nélkül a projekt befejezetlen személyes kísérletnek tűnik, nem open-source projektnek. Belépési küszöb: egy jó open-source projekt több időt vesz igénybe a karbantartásra (PR-ek áttekintése, issue-k megválaszolása), mint a kód írására.

Az open-source pet projectek sikertörténetei: Retrofit (Square), Picasso, Coil — mindegyik fejlesztők pet projectjeként indult, akik a saját problémájukat oldották meg. A Picasso (képek betöltése Androidhoz) Jake Wharton által írták egy hétvégén problémamegoldásként, és ma milliók alkalmazás használja. Pet to product — a személyes projekttől az ipari szabványig vezető út lehetséges, de nem cél önmagában.