Pet project ve vývoji aplikací — co to je, nápady a kde začít

Co je pet project a proč ho dělat

Pet project (z anglického pet project — oblíbený projekt) — je softwarový produkt, který vývojář vytváří ve volném čase pro vlastní účely: učení, experimentování nebo automatizaci osobních úkolů. Na rozdíl od práce, kde technologie a architekturu často diktuje byznys a legacy, pet project dává plnou svobodu výběru: chceš vyzkoušet Rust pro mobilní vývoj? Prosím. Chceš napsat vlastní kompilátor? Do toho.

Proč dělat pet project? První důvod — učení praxí. Teorie (knihy, kurzy, dokumentace) dává základ, ale skutečné porozumění přichází a teprve, když sám přijímáš architektonická rozhodnutí, sám opravuješ chyby a sám nasazuješ do produkce. Learning by doing — nejúčinnější způsob, jak zvládnout nový technologický stack. Druhý důvod — portfolio: zaměstnavatel vidí nejen řádek v životopise „znám Flutter”, ale skutečný projekt s architekturou, testy a CI/CD.

Třetí důvod — kariérní růst. Vývojář s pet projektem na pohovoru může ukázat kód, mluvit o architektonických rozhodnutích a prokázat porozumění celému cyklu vývoje — od nápadu po nasazení. Podle údajů Stack Overflow Survey (2025) dostávají vývojáři s veřejnými pet projekty v průměru o 15–20% více nabídek na seniorní pozice. Pet project — ne povinnost, ale investice do kariéry.

Jak vybrat nápad pro pet project

Hlavní chyba začátečníků — začít s příliš velkým nápadem: „napíšu svůj Instagram”. Pet project s obrovským rozsahem je odsouzen k opuštění po 2–3 týdnech, protože vývojář narazí na složitost a ztratí motivaci. Správná strategie: vybrat nápad, který lze dotáhnout do fungujícího prototypu za 2–4 týdny, a poté iterativně rozšiřovat. MVP mindset — minimální verze, která dělá přesně jednu věc.

Nejúspěšnější kategorie pro pet projekty: klon existující aplikace na novém stacku (sledovač návyků, správce hesel, aplikace na počasí, RSS čtečka); nástroj pro automatizaci osobního úkolu (parser životopisuů, generátor zpráv, Telegram bot); knihovna nebo plugin pro otevřenou komunitu (pohodlný obal nad API, vlastní Gradle plugin, Figma plugin). Clone project — nejlepší začátek: víš, jak by to mělo fungovat, a můžeš se soustředit na učení technologie, ne na navrhování UX.

Kritéria výběru nápadu: osobní zájem (pokud to není zajímavé — za týden to vzdáš); realizovatelné za 2–4 týdny do MVP; umožňuje použití technologie, kterou se chceš naučit; řeší skutečný problém (tvůj nebo známých). Nápady, které se nehodí: další seznam úkolů (milion analogií), kryptoměnová burza (právní soulad), sociální síť (obrovský rozsah). Goldilocks principle: není příliš jednoduchý (nuda), není příliš složitý (vzdáš to), ale je zajímavý a dosažitelný.

Výběr technologického stacku pro osobní projekt

Výběr stacku závisí na cíli pet projektu. Pokud je cílem naučit se novou technologii, stack je zřejmý: právě ta technologie. Pokud je cílem vytvořit užitečný nástroj, zvol stack, ve kterém jsi již kompetentní, abys neztrácel čas učením syntaxe. Compromise: 70% známého stacku + 30% nového. Například Android vývojář může vzít známý Kotlin + novou architekturu (MVI místo MVVM) a novou knihovnu pro animace (Compose Animation).

Pro mobilní pet projekty oblíbené kombinace: Kotlin + Jetpack Compose (Android); Swift + SwiftUI (iOS); Flutter + Dart (cross-platform); React Native + TypeScript (cross-platform). Pro backend: Kotlin + Ktor (lehký server), Go + Chi (vysoký výkon), Python + FastAPI (rychlý prototyp). Full-stack pet project může zahrnovat mobilního klienta + backend + databázi + CI/CD — to dává porozumění celému cyklu vývoje.

Důležitá rada: nesnaž se na začátku vybrat perfektní stack. Zvol to, co tě právě zajímá. Pokud za měsíc zjistíš, že stack nevyhovuje — přepiš projekt na jiný. Zkušenost s přepisováním (rewrite) — také cenná zkušenost. V pet projektu není žádný technický dluh kromě toho, který si sám vytvoříš. Freedom of choice — hlavní výhoda pet projektu oproti komerčnímu vývoji.

Jak zorganizovat proces a neopustit projekt

80% pet projektů je opuštěno v prvních 3 měsících. Důvod — ne nedostatek času, ale špatná organizace. Hlavní nepřátelé: chybějící termín (lze odložit navždy), příliš velký rozsah (demotivace z nekonečné práce), perfekcionismus (touha udělat to dokonale napoprvé). Anti-patterns: „nejprve prostuduji veškerou dokumentaci, pak začnu psát kód” — špatně. Začni psát kód od prvního dne, dokumentaci používej jako příručku.

Praktické rady pro udržení setrvačnosti: stanov pravidelný čas na projekt (např. každé úterý a čtvrtek od 20:00 do 22:00), dělej malé commity se srozumitelnými zprávami (to dává pocit pokroku), používej GitHub Issues nebo jednoduchý seznam úkolů pro plánování dalších kroků, nasazuj v časné fázi (Firebase Hosting, Vercel, GitHub Pages), abys viděl výsledek práce naživo. Ship early, ship often — princip, který funguje i pro pet projekty.

Pokud jsi vynechal týden — nevyčítej si to a nesnaž se dohánět o víkendu. Jednoduše se vrať k pravidelnému rozvrhu. Pet project by se neměl stát zdrojem stresu. Pokud už projekt nepřináší potěšení — můžeš ho odložit nebo uzavřít. Sunsetting (vědomé ukončení projektu) — normální praxe. Důležité je vyvodit poučení a případně zveřejnit kód jako referenci.

Jak přeměnit pet project v kariérní aktivum

Jen napsat kód a zapomenout — nestačí. Aby pet project fungoval ve prospěch kariéry, musí být reprezentativní. Kvalitní README — první věc, kterou recruiter nebo tech lead uvidí na GitHubu. README by měl obsahovat: popis projektu (co a proč), snímky obrazovky nebo GIF demonstraci, návod ke spuštění, popis architektury (jaké vzory, knihovny, přístupy), odkaz na živé demo (pokud je relevantní). README first impression — vizitka vývojáře.

Další prvky zvyšující hodnotu portfolia: CI/CD pipeline (odznak GitHub Actions v README ukazuje, že projekt je udržován); unit testy a UI testy (prokazují porozumění best practices testování); dokumentace architektury (ADR, diagramy); issues a PR s diskusemi (ukazují schopnost práce v týmu i v osobním projektu). Quality signals pro recruitery: testy + CI + README + struktura > počet hvězd nebo commitů.

Jak zmínit pet project v životopisu: samostatná sekce „Personal Projects” se 2–4 projekty. Pro každý: název, odkaz na GitHub, stack, 2–3 věty o úkolu a řešení. Pokud má projekt aktivní uživatele (přátelé, rodina) nebo je publikován v obchodě — určitě uveď počet instalací/stažení. Metrics: „Pet projekt ve Flutteru, 50+ instalací v Google Play, CI/CD přes GitHub Actions, 85% pokrytí testy” řekne víc než „znám 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

Důležité: neměň sekci pet projektů ve skládku 20 opuštěných repozitářů. Vyber 2–3 nejlepší, kde je kód v pořádku, README vyplněno, testy procházejí. Curated portfolio má větší hodnotu než množství.

Kdy se pet project stává open-source projektem

Ne každý pet project musí být open-source. Pokud projekt řeší tvůj osobní úkol a pravděpodobně nebude užitečný ostatním — soukromý repozitář je naprosto v pořádku. Ale pokud projekt implementuje funkcionalitu, kterou jiní vývojáři hledají (knihovna, plugin, nástroj), stojí za to ho zveřejnit. Open-source dodává viditelnost, zpětnou vazbu od komunity a buduje reputaci ve vývojářské komunitě.

Klíčové prvky open-source pet projektu: licence (MIT, Apache 2.0 — nejčastější); CONTRIBUTING.md (jak přispívat); šablony issue (bug report, feature request); code of conduct; sémantické verzování s release tagy. Bez těchto prvků projekt vypadá jako nedokončený osobní experiment, ne jako open-source projekt. Bariéra vstupu: dobrý open-source projekt zabere více času na údržbu (kontrola PR, odpovídání na issue) než na psaní kódu.

Příběhy úspěchu open-source pet projektů: Retrofit (Square), Picasso, Coil — všechny začaly jako pet projekty vývojářů, kteří řešili svůj vlastní problém. Picasso (načítání obrázků pro Android) napsal Jake Wharton během víkendu jako řešení problému a nyní ho používají miliony aplikací. Pet to product — cesta od osobního projektu k průmyslovému standardu je možná, ale neměla by být sama o sobě cílem.