Portfolio programisty: 7 projektów, które naprawdę robią wrażenie na rekruterach

Masz kilka repozytoriów na GitHubie, ale w rekrutacji cisza. Albo masz projekty z bootcampu, które wyglądają „jak u wszystkich”, więc trudno nimi wygrać. Rekruter i osoba techniczna zwykle nie czytają kodu od deski do deski — skanują sygnały: czy projekt działa, czy umiesz domykać temat, czy potrafisz opisać decyzje i czy wiesz, co jest ważne w produkcie.

Portfolio programisty nie musi być duże. Ma być czytelne, dowożone i łatwe do zweryfikowania w minutę: demo, README, sensowny zakres, kilka mocnych decyzji technicznych, minimum jakości (testy tam, gdzie mają sens, podstawy bezpieczeństwa, sensowna struktura repo). Poniżej masz procedurę wyboru oraz 7 typów projektów, które realnie robią wrażenie na rekruterach — razem z ostrzeżeniami, kiedy dany projekt może być stratą czasu.

Najpierw cel: jaka rola, jakie sygnały kompetencji, ile projektów ma sens

Mapowanie roli na „sygnały”, które da się pokazać w repo i demo

Zamiast budować „cokolwiek”, wybierz docelową rolę i zamień ją na 3–5 umiejętności, które muszą być widoczne. To działa lepiej niż lista technologii w CV.

• Frontend: praca na danych (API), formularze, stany UI (loading/error/empty), dostępność, architektura komponentów, podstawy wydajności.
• Backend: kontrakt API, model danych, walidacja, obsługa błędów, auth, testy, migracje, logowanie.
• Fullstack: spójność end-to-end, sensowny podział warstw, wdrożenie, podstawy bezpieczeństwa.
• Mobile: offline/niestabilna sieć, nawigacja, stan aplikacji, integracja z API, jakość UI na urządzeniach.
• Data: pipeline, walidacja danych, powtarzalność, eksperymenty, raportowanie, interpretacja wyników.
• DevOps: IaC, CI/CD, obserwowalność, bezpieczeństwo sekretów, stabilne wdrożenia.

To mapowanie przyda się później do oceny projektów: czy dany pomysł faktycznie pokazuje to, co obiecujesz w CV.

Zasada 2–4 projektów: jakość wygrywa z ilością

Najczęstszy błąd portfolio juniora: 8–12 repo, z czego 6 to tutoriale, 4 nie mają demo, a README jest jednym zdaniem. W rekrutacji wygrywa 2–4 projekty doprowadzone do stanu „do pokazania”.

Praktyczny układ, który zwykle działa:

• 1 projekt produktowy end-to-end (najlepszy „magnes” do rozmowy).
• 1 projekt inżynierski (jakość, testy, architektura, refaktor, obserwowalność).
• opcjonalnie 1 projekt integracyjny (zewnętrzne API, kolejka, cache, odporność na awarie).
• opcjonalnie 1 projekt specjalizacyjny (np. data, devops, mobile).

Jeśli masz mało czasu: postaw na 2 projekty. Jeśli masz NDA i nie możesz pokazać kodu z pracy: zbuduj 3 projekty, ale utrzymaj je mniejsze.

„Sygnały dowożenia” zamiast „szyldu technologii”

Rekruterzy lubią technologie, ale zatrudniają za dowożenie. Co zwykle czyta się lepiej niż „użyłem X i Y”:

• działające demo (albo krótkie wideo),
• jasna definicja zakresu i ograniczeń,
• 3–5 decyzji technicznych opisanych w README,
• obsłużone „brzydkie” przypadki: błędy, puste dane, uprawnienia, walidacja,
• sensowny proces pracy: commity, issues, podstawowe CI.

Flow decyzyjny krok po kroku: jak wybrać 2–3 projekty w tydzień, a nie w miesiąc

Krok 1 — wybierz jedną ofertę docelową i przepisz wymagania na język funkcji

Weź jedną realną ofertę pracy (nawet jeśli „trochę za mocna”) i wypisz wymagania nie jako technologie, tylko jako to, co kandydat ma umieć zrobić.

• Zamiast „React”: formularze, zarządzanie stanem, integracja z API, dostępność.
• Zamiast „Node.js”: API, walidacja, auth, testy, praca z bazą.
• Zamiast „AWS”: wdrożenie, infrastruktura jako kod, logi/metryki, sekrety.

To usuwa chaos. Potem wybierasz projekt, który te „funkcje” pokaże bez dopisywania 30 narzędzi do stacku.

Krok 2 — dopasuj typ projektu do umiejętności, które chcesz udowodnić

Każdy projekt w portfolio powinien mieć 1–2 mocne tezy. Przykłady:

• „Umiem dowieźć aplikację end-to-end” → mini-SaaS, panel, role, wdrożenie.
• „Umiem pisać backend pod realne użycie” → REST + baza + testy + OpenAPI + logi.
• „Umiem robić UI w jakości produkcyjnej” → stany, a11y, formularze, błędy, wydajność.
• „Umiem integrować i robić odporność” → zewnętrzne API, cache, retry, rate limit, fallback.

Jeśli projekt nie umie powiedzieć „co udowadnia” w jednym zdaniu, zwykle jest zbyt rozmyty.

Krok 3 — oceń ryzyko i czas: scope, zależności, integracje, UI

Rekrutacyjnie wygrywa projekt dowieziony. Dlatego oceniaj pomysły przez ryzyko, a nie „fajność”. Najczęstsze ryzyka:

• zbyt szeroki zakres (np. „aplikacja jak Jira” bez brutalnego cięcia funkcji),
• zależność od niestabilnych API (demo przestaje działać),
• dużo UI i brak czasu (frontend pożera tygodnie),
• przeinżynierowanie (mikroserwisy, DDD, Kubernetes bez potrzeby).

Jeśli celujesz w 2–4 tygodnie pracy po godzinach, trzymaj scope mały: jedna domena, jedna główna ścieżka użytkownika, maks. 1–2 integracje.

Krok 4 — zdefiniuj DONE zanim napiszesz pierwszą linijkę kodu

Definicja „DONE do portfolio” nie brzmi: „jest w miarę”. Brzmi: da się uruchomić, da się pokazać, jest opisane. Minimalna definicja DONE (przykładowa):

• działające demo lub wideo walkthrough (90 sekund),
• README z instrukcją uruchomienia i decyzjami,
• obsłużone błędy/walidacja w kluczowej ścieżce,
• testy dla krytycznych elementów (nie „wszystko”),
• brak sekretów w repo, sensowna konfiguracja.

Prosty scoring (0–2), który ułatwia wybór bez rozkmin

Każdy pomysł oceń w trzech kategoriach. 0–2 punkty, maks. 6:

Wybieraj projekty 5–6/6. Te na 3–4/6 nadają się, jeśli mocno utniesz scope.

Standard „projekt gotowy do portfolio”: definicja DONE + elementy, które rekruter skanuje w 60 sekund

Jak wygląda skanowanie projektu w praktyce

Typowa kolejność patrzenia na projekt rekrutacyjny GitHub jest dość powtarzalna:

1. Link do demo (albo wideo) — czy działa i czy widać sens.
2. 2–3 screeny/GIF — czy produkt ma funkcję, nie tylko UI.
3. README — czy rozumiem, co to jest i jak uruchomić.
4. Struktura repo — czy jest porządek i podział odpowiedzialności.
5. Testy/CI — czy ktoś myśli o jakości.
6. Historia commitów/issues — czy praca wygląda jak projekt, a nie jednorazowy zrzut.

Jeśli nie ma demo i README, wiele osób kończy oglądanie na 30 sekundzie.

Demo (albo wideo) jako pierwszy punkt zaczepienia

Demo nie musi być „produkcyjne”, ale ma być stabilne. Jeśli projekt zależy od API, które bywa niedostępne — zrób tryb mock/fallback.

Minimalny zestaw, który zwykle wystarcza:

• publiczny link (Netlify/Vercel/Render/Fly/inna platforma) lub łatwy docker-compose,
• konto demo (login/hasło) albo tryb „Explore as guest”,
• seed danych: żeby nie oglądać pustej aplikacji,
• krótki opis: co kliknąć jako pierwsze.

Gdy nie da się zrobić demo (np. projekt infrastrukturalny), wideo walkthrough jest lepsze niż „uruchom lokalnie”.

README, które prowadzi jak instrukcja i sprzedaje decyzje

Dobre README do projektu portfolio to nie opis narzędzi. To dokument, który skraca drogę do rozmowy technicznej. Minimalny szablon treści:

• 1–2 zdania: problem i dla kogo.
• Funkcje: MVP (co działa) + opcjonalne (co planowałeś, ale świadomie odciąłeś).
• Demo / wideo + screeny.
• Stack (krótko) i uzasadnienie 2–3 wyborów.
• Jak uruchomić (lokalnie), najlepiej w 5–10 komendach maks.
• Testy: jak odpalić i co pokrywają.
• Decyzje i kompromisy: 3–5 punktów (np. „JWT vs sesja”, „cache”, „monolit modułowy”).
• Znane ograniczenia i plan rozwoju (krótko, bez roadmapy na rok).

Jeśli masz czas na jeden „bonus”, dodaj mały diagram architektury (nawet ASCII albo obrazek z narzędzia do diagramów).

Jakość repo: struktura, testy krytycznych ścieżek, podstawowe bezpieczeństwo

„Jakość” w portfolio nie oznacza perfekcji. Oznacza brak czerwonych flag. Co zwykle daje najlepszy zwrot:

• czytelna struktura: moduły, warstwy, sensowne nazwy, bez „utils” na wszystko,
• lint/format i spójne konwencje,
• testy krytycznych ścieżek: logika domenowa, endpointy, walidacje, najważniejsze komponenty UI,
• obsługa błędów: komunikaty, kody HTTP, fallback w UI,
• bezpieczeństwo podstawowe: brak sekretów w repo, walidacja wejścia, sensowny auth, ograniczenia CORS tam, gdzie trzeba.

Mikroserwisy, CQRS, event sourcing — to może być imponujące, ale często wygląda jak przerost formy. Jeśli nie umiesz w dwóch zdaniach uzasadnić, po co to jest, lepiej uprościć.

7 projektów, które robią wrażenie — typy, warianty na stacki, kryteria ukończenia i ostrzeżenia

1) Aplikacja „produktowa” end-to-end (mini-SaaS)

Co ten projekt udowadnia w rekrutacji

To najsilniejszy typ projektu do portfolio programisty, bo pokazuje pełen cykl: funkcja → implementacja → UX → wdrożenie. Dla juniora to sygnał „umiem dowieźć”, dla mida: „umiem projektować i domykać”.

Najlepiej działają mini-produkty z jasną domeną, np. prosty CRM dla freelancerów, rezerwacje zasobów, budżet domowy z kategoriami, śledzenie nawyków z celami i raportem, panel do zarządzania treścią.

Minimalne DONE (żeby projekt był rekrutacyjny, nie „szkoleniowy”)

• Jedna główna ścieżka użytkownika: np. „dodaj → edytuj → filtruj → eksportuj” (albo inny sensowny ciąg).
• CRUD + walidacja (po stronie API i UI, jeśli dotyczy).
• Auth albo świadomy brak auth z uzasadnieniem (np. demo-only).
• Role/uprawnienia w minimalnej wersji (np. admin/user) lub inny element, który pokazuje myślenie o dostępie.
• Stany UI: loading/error/empty + sensowne komunikaty.
• Wdrożenie: publiczny link + seed danych i konto demo.

Ostrzeżenia (kiedy ten typ projektu bardziej szkodzi niż pomaga)

Najczęstsza pułapka to „SaaS bez produktu”: masa ustawień, paneli i tabel, a brak jednej funkcji, która realnie rozwiązuje problem. Jeśli nie umiesz streścić wartości w jednym zdaniu, zakres zacznie puchnąć i projekt ugrzęźnie w UI.

Drugi klasyk: auth i uprawnienia robione na końcu. Nagle okazuje się, że modele danych i endpointy trzeba przepisać, bo nie ma pojęcia „właściciel” ani „organizacja”. Lepiej od razu zdecydować: single-user, multi-user czy organizacje — i trzymać się tego do końca.

Trzecia rzecz to „produkcyjność udawana”: zewnętrzne integracje bez trybu fallback, brak seedów, brak konta demo. Rekruter kliknie, zobaczy puste ekrany albo błąd 500 i zamknie kartę, nawet jeśli kod jest niezły.

Ten typ wybieraj, gdy chcesz pokazać całość i masz czas dopiąć demo. Jeśli walczysz z czasem, lepszy jest mniejszy projekt z jedną mocną rzeczą (np. świetna logika domenowa albo przemyślane API) niż mini-SaaS, który wygląda na niedokończony.

Najlepsze portfolio wygląda jak mała półka z produktami: 2–3 rzeczy dowiezione, łatwe do uruchomienia i opisane bez marketingu. Dobierz projekty pod rolę, trzymaj scope w ryzach i pilnuj definicji DONE — reszta to już tylko rozmowa techniczna.

2) API „jak w pracy”: serwis z dokumentacją, testami i kontraktem

Co ten projekt udowadnia w rekrutacji

To mocny sygnał dla backendu (i fullstacku), bo pokazuje, że umiesz projektować interfejs, a nie tylko „wystawiać endpointy”. Dobrze wygląda też u osób, które nie mogą pokazać kodu z pracy (NDA) — bo API łatwo odtworzyć w wersji neutralnej domenowo.

Warianty na stacki (wybierz jeden)

• Node.js: Express/Nest + OpenAPI + testy integracyjne (Supertest).
• Java/Kotlin: Spring Boot + Swagger + Testcontainers.
• .NET: Minimal API/ASP.NET + Swashbuckle + xUnit.
• Python: FastAPI + Pydantic + pytest.

Minimalne DONE (żeby nie wyszło „CRUD demo”)

• OpenAPI/Swagger generowane i dostępne pod /docs (albo statycznie w repo).
• Walidacja i spójne błędy: format odpowiedzi błędów, kody HTTP, komunikaty.
• Auth w prostej, czytelnej wersji: JWT lub sesja (plus refresh/wygaśnięcie opisane).
• Paginated list + filtrowanie/sortowanie (chociaż jedno) – realny element „produkcyjny”.
• Testy integracyjne dla kluczowych endpointów (szczęśliwa ścieżka + 1–2 błędy).
• docker-compose do uruchomienia API + DB jednym poleceniem.
• Prosty klient do demo: curl/HTTPie, Postman collection albo mały front (może być brzydki, ma działać).

Kryteria sprawdzenia przed publikacją

1. Nowa osoba odpala projekt z README w < 10 minut (bez „zainstaluj jeszcze X i popraw PATH”).
2. Swagger pokazuje przykładowe request/response (bez pustych schematów).
3. Brak „magii” w konfiguracji: env przykładowy (.env.example) i jasny opis.

Ostrzeżenia

Najczęściej psuje efekt „API bez historii”: endpointy są, ale nie widać powodu istnienia reguł. Dodaj 2–3 proste zasady domenowe (np. statusy, przejścia, limity) i przetestuj je.

Druga pułapka to security jako dekoracja: JWT bez weryfikacji uprawnień, admin „na słowo”. Lepiej mieć jeden zasób z realnym sprawdzeniem właściciela niż dziesięć endpointów bez kontroli dostępu.

3) Projekt z „trudniejszą logiką” (algorytmy domenowe, nie LeetCode)

Co ten projekt udowadnia w rekrutacji

Tu wygrywa nie UI, tylko myślenie: modelowanie, testowalność, czytelne reguły, edge case’y. Ten typ działa świetnie, gdy Twoje repo wygląda na „same apki” bez głębi.

Przykładowe domeny, które łatwo obronić

• Silnik cen/promocji: kupony, progi, wykluczenia, priorytety.
• Planowanie: wykrywanie kolizji rezerwacji, zasady dostępności, strefy czasowe.
• Workflow: statusy i przejścia (np. zgłoszenia), walidacja przejść, audyt zmian.
• Parser/validator: import CSV/JSON z raportem błędów per rekord (a nie „fail fast”).

Minimalne DONE

• Wyraźny model: encje/typy + reguły w jednym miejscu (bez logiki rozlanej po kontrolerach).
• Testy: zestaw scenariuszy i przypadków brzegowych (to tu robi wrażenie).
• Opis reguł w README (krótko) + 2–3 przykładowe wejścia/wyjścia.
• Małe demo: CLI, endpoint albo strona „playground”, gdzie da się wprowadzić dane i zobaczyć wynik.

Ostrzeżenia

Nie wybieraj logiki, której nie da się sensownie opisać w 5–7 zdaniach. Jeśli potrzebujesz strony A4, by wyjaśnić problem, rekruter raczej nie poświęci czasu.

Uważaj też na „ładny kod bez użycia”: sama biblioteka z funkcjami wygląda abstrakcyjnie. Dodaj minimalny interfejs (CLI/endpoint), żeby było co kliknąć lub wywołać.

4) Frontend, który pokazuje pracę z danymi: dashboard/analiza z realnymi stanami

Co ten projekt udowadnia w rekrutacji

Rekruter techniczny szybko widzi, czy umiesz ogarniać typowe problemy FE: cache, błędy, formularze, dostępność, rozbijanie komponentów, wydajność list. To jest bardziej „rekrutacyjne” niż landing page.

Minimalne DONE

• Praca na danych: lista + szczegóły + filtrowanie/sortowanie + paginacja lub infinite scroll.
• Stan sieci: loading/error/empty + retry, komunikaty bez „Something went wrong”.
• Formularz z walidacją i sensowną obsługą błędów z API.
• Cache i synchronizacja (np. React Query/SWR): invalidacja po mutacji, optimistic update lub świadomy brak.
• Jeden element jakości: a11y dla kluczowych elementów albo testy komponentów (najważniejsze ścieżki).
• Demo z seeded danymi (albo mock serwerem), żeby aplikacja nie była pusta.

Szybka checklista UX (30 minut, a podnosi ocenę)

• Czy da się obsłużyć aplikację klawiaturą w głównym przepływie?
• Czy błędy walidacji mówią, co poprawić (a nie tylko „invalid”)?
• Czy po zapisie widać efekt (toast/zmiana widoku), a nie cisza?

Ostrzeżenia

Nie buduj „dribbble app”: piękny UI bez zderzenia z API i błędami nie pokazuje pracy w realnym produkcie. Lepiej brzydszy interfejs, ale z dobrze ogarniętymi stanami i danymi.

Druga pułapka to zbyt dużo bibliotek. Jeśli używasz design systemu, tabel i wykresów, ogranicz resztę. Rekruter ma zobaczyć Twoje decyzje, nie listę zależności.

5) Integracja z zewnętrzną usługą (płatności, e-mail, mapy, pliki) z trybem sandbox

Co ten projekt udowadnia w rekrutacji

Integracje są codziennością w firmach. Ten typ projektu pokazuje, że umiesz czytać dokumentację, obsłużyć webhooki, błędy, idempotencję i konfigurację środowisk.

Minimalne DONE

• Jedna integracja i jedna konkretna wartość (np. „wygeneruj fakturę PDF i wyślij”, „płatność + webhook potwierdzenia”).
• Tryb sandbox + opis jak przetestować (krok po kroku).
• Obsługa błędów: time-out, 4xx/5xx, ponowienie lub komunikat do użytkownika.
• Webhooki (jeśli dotyczy): weryfikacja podpisu + idempotencja (chociaż prosta).
• Bezpieczna konfiguracja: sekrety tylko w env, rotowalne klucze, brak logowania wrażliwych danych.

Ostrzeżenia

Integracje potrafią zabić czas. Jeśli dokumentacja jest słaba, a debug ciężki, ogranicz cel do jednego przepływu i jednego webhooka. Reszta w „known limitations” w README.

Nie pokazuj w repo „prawie działających” kluczy i screenów z paneli. Nawet jeśli są unieważnione, wygląda to jak błąd higieny.

6) Projekt „DevOps-lite”: CI/CD + obserwowalność + sensowne wdrożenie

Co ten projekt udowadnia w rekrutacji

To działa, gdy celujesz w role, gdzie liczy się dowożenie i utrzymanie: fullstack, backend, platform/devops. Pokazuje, że rozumiesz proces, a nie tylko kod.

Minimalne DONE

• Pipeline CI: lint + testy + build (GitHub Actions/GitLab CI).
• Wdrożenie: jeden klik/merge do main i aplikacja jest aktualna (nawet na prostej platformie).
• Healthcheck i podstawowy monitoring stanu (endpoint /health, proste logi).
• Konfiguracja środowisk: dev/prod rozdzielone (chociażby przez env).
• Dockerfile i/lub docker-compose – spójne z README.

Ostrzeżenia

Nie wchodź w Kubernetes, jeśli nie jest to kluczowy wymóg Twojej roli. Często wygląda to jak „przerost narzędzia” i odciąga uwagę od produktu. Lepszy prosty deploy + sensowne logowanie niż klaster, którego nie umiesz utrzymać.

7) Case study „NDA-friendly”: projekt odtwarzający realny problem bez kopiowania kodu

Co ten projekt udowadnia w rekrutacji

To wyjście dla osób, które mają doświadczenie, ale nie mogą pokazać nic z pracy. Dobrze zrobiony case study pokazuje dojrzałość: umiesz opisać decyzje, kompromisy i ryzyka.

Jak to zrobić, żeby było etycznie i rekrutacyjnie mocno

• Wybierz neutralną domenę: np. „system zgłoszeń”, „katalog produktów”, „rezerwacje”, „powiadomienia”.
• Odtwórz problem, nie rozwiązanie: podobne typy ekranów/endpointów, ale inne nazwy, inne dane, brak firmowych szczegółów.
• Opisz decyzje w README: co bywało trudne (np. spójność, migracje, wydajność), jak do tego podszedłeś w wersji demo.
• Dodaj „operacyjne” elementy: migracje DB, retry, kolejka (jeśli ma sens), metryki/logi.

Minimalne DONE

• Repo działa end-to-end (lokalnie lub jako demo).
• README ma sekcję „Czego tu nie ma i dlaczego” (to często wygląda lepiej niż udawanie pełnego produktu).
• Jest jedna rzecz, która wygląda „jak z pracy”: np. migracje, wersjonowanie API, idempotencja, feature flag w prostej wersji.

Ostrzeżenia

Nie próbuj „udowodnić”, że robiłeś dokładnie to samo w firmie. Wystarczy, że pokażesz typ problemu i sposób myślenia. Rekruterzy są wyczuleni na zbyt podobne nazwy, modele i screenshoty.

Checklista publikacji: ostatnie 90 minut przed wysłaniem linku rekruterowi

• Demo działa: klikam link i widzę sensowny stan startowy (seed/guest).
• README na górze: pierwszy ekran mówi, co to jest i jak to uruchomić.
• Instalacja nie boli: brak brakujących kroków, brak „zrób sobie bazę ręcznie”.
• Testy odpalają się: jedna komenda, a wynik jest przewidywalny.
• Brak sekretów: skan folderów .env, kluczy, tokenów; jest .env.example.
• Repo jest czytelne: sensowne nazwy, brak „final-final-v2”, krótki opis commitów.
• Ograniczenia są nazwane: 3–5 punktów, bez usprawiedliwień.

Najczęstsze czerwone flagi (i szybkie naprawy)

• „Nie da się uruchomić” → dodaj docker-compose albo popraw README do wersji „kopiuj-wklej”.
• „Puste demo” → seed danych + konto demo + krótka instrukcja „kliknij tu”.
• „Wszystko w jednym pliku” → wydziel moduły/warstwy dla jednej krytycznej ścieżki (nie refaktoruj całego świata).
• „Auth jest, ale nic nie chroni” → dodaj jeden zasób z kontrolą właściciela i testem.
• „Brak błędów” (czyli crash) → centralny handler błędów w API / sensowne fallbacki w UI.

Jak ułożyć 2–4 projekty w portfolio, żeby rekruter „złapał” sygnał w 30 sekund

Najczęstszy problem to nie brak projektów, tylko brak czytelnej narracji: co umiesz i w jakim kontekście. Układ ma prowadzić od „co to robi” do „jak to działa” i „jak to uruchomić”.

Krok 1: Jeden projekt = jeden główny sygnał kompetencji

Jeśli projekt ma być fullstackiem, integracją, DevOps i algorytmami naraz, rozmywa się. Lepiej, żeby każdy projekt miał jeden temat przewodni i 2–3 tematy poboczne.

• Przykład sygnału: „API + autoryzacja i testy” (backend) albo „UI na danych + obsługa stanów sieci” (frontend).
• Tematy poboczne: np. CI, podstawy bezpieczeństwa, proste logowanie.

Krok 2: Ustal kolejność w portfolio (to zmienia odbiór)

Na górę daj projekt, który da się kliknąć i od razu rozumie się wartość. GitHub z samymi repo bez dem jest ok, ale jako drugi rzut oka.

1. #1 „klikany”: działające demo + sensowne dane startowe.
2. #2 „techniczny”: API/CI/testy/architektura, nawet jeśli bez ładnego UI.
3. #3 „wyróżnik”: integracja, DevOps-lite albo NDA-friendly case study.
4. #4 (opcjonalnie): mały projekt pokazujący jeden skill (np. biblioteka, narzędzie CLI).

Krok 3: Standard opisu na stronie projektu (README), który przechodzi skan

README ma działać jak instrukcja obsługi i skrót architektury. Bez eseju.

• 1–2 zdania: co to jest i dla kogo.
• Linki: demo, repo, dokumentacja API (jeśli jest), ewentualnie krótki GIF.
• Funkcje: 5–8 punktów, w kolejności wartości dla użytkownika.
• Jak uruchomić: „kopiuj-wklej” (lokalnie i/lub docker).
• Architektura: 5–10 zdań + jeden prosty diagram (opcjonalnie).
• Decyzje i kompromisy: 3–6 punktów („wybrałem X, bo…”, „nie zrobiłem Y, bo…”).
• Known limitations: nazwane ograniczenia bez tłumaczenia się.

Ostrzeżenie: demo bez instrukcji to prawie jak brak demo

Jeśli trzeba zgadywać, gdzie kliknąć, rekruter często odpuszcza. Dodaj sekcję „Scenariusz 2 minuty”: 4–6 kroków, które pokazują kluczowe funkcje.

Checklisty „przed / w trakcie / po”: jak dowieźć projekt bez rozjechanego scope

Przed startem (30–60 minut)

• Spisz user flow w 6–10 krokach (co użytkownik robi po kolei).
• Zamknij MVP do 1–2 ekranów lub 3–5 endpointów.
• Wybierz ryzyka: max 2 trudne rzeczy (np. webhook + idempotencja). Reszta prosta.
• Wybierz sposób deployu od razu (żeby nie „dopinać” na końcu w panice).

W trakcie (codziennie, 10 minut kontroli)

• Czy najważniejsza ścieżka działa end-to-end?
• Czy dokładane elementy wzmacniają sygnał, czy tylko „ładnie brzmią”?
• Czy w repo nie rośnie bałagan: foldery, nazwy, skrypty?

Po dowiezieniu MVP (2–3 godziny „polerki”, która robi różnicę)

• Seed danych lub tryb guest — bez pustych ekranów.
• Jedna rzecz jakości: testy dla krytycznej ścieżki albo a11y, albo bezpieczeństwo (np. uprawnienia do zasobu).
• Stabilność: sensowne komunikaty błędów + retry tam, gdzie to ma sens.
• Porządek w uruchamianiu: jeden command do startu, jeden do testów.

Mini-procedura: jak w 15 minut ocenić, czy projekt jest „tutorialowy”

To nie kwestia tego, czy używasz popularnego kursu. Chodzi o to, czy projekt ma własne decyzje i realistyczne krawędzie.

1. Sprawdź problem: czy w 2 zdaniach da się powiedzieć, jaka jest wartość dla użytkownika?
2. Sprawdź dane: czy są realne stany (brak wyników, błędy, konflikt zapisu), czy tylko „happy path”?
3. Sprawdź decyzje: czy README ma sekcję „trade-offs” i ograniczenia?
4. Sprawdź uruchomienie: czy ktoś obcy odpali to bez domysłów?
5. Sprawdź higienę: brak sekretów, przewidywalne skrypty, sensowne commity.

Szybki test „czy ja to rozumiem jako rekruter?”

• Po wejściu w repo w 60 sekund wiem: co to robi, jak uruchomić, co kliknąć.
• W 3 minuty widzę jedną trudniejszą rzecz: auth, webhook, cache, migracje, testy.

Ostrzeżenia końcowe: rzeczy, które najczęściej marnują tygodnie

• Przerost stacku: dokładanie narzędzi, żeby „wyglądało seniorowo”, często obniża czytelność. Lepiej mniej, ale z uzasadnieniem.
• Za duży produkt: marketplace, social network, „mini Uber” — zwykle kończy się niedokończeniem. Zmniejsz do jednego flow.
• Brak dowodu działania: repo bez demo i bez seeded danych wygląda jak kod do oceny, nie jak gotowy kawałek produktu.
• Udawanie produkcji: mikroserwisy, K8s, skomplikowana observability bez potrzeby — jeśli nie umiesz tego obronić w rozmowie, to ryzyko.

Decyzja: które typy projektów wybrać w zależności od roli

Jeśli masz zrobić tylko 2–3 projekty, dobierz je tak, żeby pokryły „must have” dla roli i dały jeden wyróżnik.

• Frontend: #4 (dashboard na danych) + #2 (projekt z testami/architekturą FE) + opcjonalnie #5 (integracja, np. mapy/pliki).
• Backend: #1 (API + auth/role) + #5 (integracja + webhook) + #6 (CI/CD + deploy + healthcheck).
• Fullstack: #1 lub #3 (mini produkt) + #4 (FE na danych) + #6 (wdrożenie i pipeline).
• DevOps/Platform: #6 jako główny + #5 (integracja/sekrety/webhook) + mały projekt narzędziowy (CLI) jako trzeci.
• Gdy masz NDA: #7 jako oś + jeden „klikany” projekt (#3 lub #4) dla szybkiego wejścia w portfolio.

Najczęściej zadawane pytania (FAQ)

Ile projektów powinno być w portfolio programisty?

Najczęściej wygrywa 2–4 projektów doprowadzonych do stanu „da się pokazać i zweryfikować w minutę”. Lepsze są dwa mocne repo niż dziesięć rozpoczętych.

Praktyczny układ to: jeden projekt end-to-end (produktowy) + jeden projekt „inżynierski” (testy, architektura, jakość). Reszta tylko jeśli masz czas i sensowny powód.

Jakie projekty najbardziej robią wrażenie na rekruterach?

Takie, które wysyłają czytelne sygnały dowożenia: działające demo, sensowny zakres, obsługa błędów i decyzje techniczne opisane w README. Rekruter i osoba techniczna zwykle skanują te elementy, a nie czytają cały kod.

Najmocniej „otwierają rozmowę” projekty produktowe end-to-end (np. panel z rolami i autoryzacją) oraz projekty pokazujące jakość (testy, CI, logowanie, sensowna struktura repo).

Jak wybrać projekt do portfolio pod konkretną rolę (frontend/backend/fullstack)?

Zamiast wybierać po technologii, wybierz po umiejętności, którą masz udowodnić. Weź jedną ofertę docelową i przepisz wymagania na „funkcje” (np. formularze i stany UI, kontrakt API i walidacja, wdrożenie i podstawy bezpieczeństwa).

Potem dobierz projekt, który te funkcje pokaże jasno w demo i README. Jeśli nie da się streścić projektu w jednym zdaniu („co udowadnia”), zwykle scope jest rozmyty.

Co musi mieć projekt na GitHubie, żeby rekruter nie zamknął go po 30 sekundach?

Najczęściej liczą się trzy rzeczy: demo lub krótkie wideo, czytelne README i możliwość szybkiego uruchomienia. Bez tego projekt wygląda jak porzucony, nawet jeśli kod jest niezły.

• link do demo (albo 90-sekundowe walkthrough),
• 2–3 screeny/GIF pokazujące funkcję, nie tylko UI,
• README: co to jest, jak uruchomić, jakie decyzje techniczne podjąłeś,
• podstawowe testy/CI tam, gdzie to ma sens,
• brak sekretów w repo i sensowna konfiguracja.

Jak napisać README do projektu portfolio, żeby „sprzedawało” decyzje?

README ma skracać drogę do rozmowy technicznej. Dwie rzeczy robią największą różnicę: jasny problem (dla kogo i po co) oraz 3–5 decyzji technicznych z uzasadnieniem, nie lista narzędzi.

Minimalny układ: opis problemu (1–2 zdania), lista funkcji (MVP + świadomie ucięte), link do demo/wideo + screeny, krótki stack, jak uruchomić w kilku komendach, testy (jak odpalić i co obejmują), kompromisy (co byś zrobił inaczej przy większym czasie).

Czy projekty z bootcampu mają sens w portfolio?

Mają, jeśli je „odkleisz” od szablonu: doprowadzisz do stabilnego demo, dopiszesz porządne README i dołożysz elementy, których zwykle brakuje w projektach „jak u wszystkich” (walidacja, obsługa błędów, uprawnienia, testy krytycznej ścieżki, CI).

Jeśli projekt wygląda identycznie jak u innych uczestników, lepiej potraktować go jako bazę i zrobić jeden mocny refaktor albo dobudować jedną konkretną przewagę (np. tryb offline w mobile, fallback/mocking przy zewnętrznym API, sensowny model danych i migracje w backendzie).

Jak ocenić, czy projekt jest za duży i stanie się stratą czasu?

Najczęstsze czerwone flagi to: „aplikacja jak Jira”, dużo UI bez jasnej ścieżki użytkownika, niestabilne integracje oraz przeinżynierowanie (mikroserwisy, Kubernetes, DDD bez potrzeby). Rekrutacyjnie wygrywa dowiezienie, nie ambicja.

Pomaga prosty scoring 0–2 w trzech punktach: czy pokaże kluczową kompetencję, czy dowieziesz w 2–4 tygodnie, czy da się to łatwo zademonstrować. Jeśli nie dobijasz do 5–6/6, tnij scope albo zmień pomysł.

Kluczowe Wnioski

• Brak odzewu zwykle nie wynika z „za mało repo”, tylko z braku czytelnych sygnałów: czy projekt działa, ma demo, sensowny README i pokazuje, że umiesz domykać temat.
• Zacznij od docelowej roli i zamień ją na 3–5 umiejętności do pokazania w kodzie i demo (np. backend: walidacja, auth, obsługa błędów, testy, migracje), zamiast polować na kolejne technologie.
• Trzymaj się zasady 2–4 projektów: lepiej mieć dwa dowiezione (demo + opis + „brzydkie przypadki”) niż 10 tutoriali bez uruchamialnego efektu.
• Ułóż portfolio jak zestaw „dowodów”: 1 projekt end-to-end jako magnes do rozmowy, 1 projekt inżynierski (jakość, testy, architektura), a dopiero potem ewentualnie integracyjny i specjalizacyjny.
• Każdy projekt powinien mieć 1–2 mocne tezy w jednym zdaniu (np. „umiem integrować i robić odporność: retry, rate limit, fallback”) — jeśli nie da się tego powiedzieć prosto, scope jest rozmyty.
• Oceniaj pomysły przez ryzyko dowiezienia, nie „fajność”: utnij zakres (jedna domena, jedna główna ścieżka użytkownika), uważaj na niestabilne API i nie pchaj mikroserwisów/Kubernetes, jeśli nie są potrzebne.
• Zdefiniuj DONE zanim zaczniesz: działające demo albo 90-sekundowe wideo, README z decyzjami i uruchomieniem, obsłużone błędy/walidacja, testy dla krytycznych elementów, zero sekretów w repo (to często robi większe wrażenie niż kolejny framework).