Jak budować portfolio po hackathonie: repozytorium, opis projektu i prezentacja

Dlaczego hackathon to złoto dla portfolio, jeśli dobrze je „opakujesz”

Hackathon sam w sobie nie buduje portfolio. Robi to to, co zrobisz z projektem po wydarzeniu: repozytorium, opis projektu, prezentacja, case study, a czasem nawet mini–strona produktowa. Ten etap decyduje, czy hackathon będzie jednym z wielu „fajnych weekendów”, czy realnym krokiem do lepszej pracy, stażu lub zleceń.

Portfoliosz po hackathonie ma kilka unikalnych przewag nad zwykłymi pet–projectami:

• pokazuje umiejętność pracy pod presją czasu,
• udowadnia zdolność współpracy w zespole i dzielenia ról,
• zawiera realny problem biznesowy lub społeczny (a nie „kolejną to-do listę”),
• często obejmuje pełny przepływ: od pomysłu, przez prototyp, po demo.

Żeby to zadziałało, projekt po hackathonie musi zostać uporządkowany, opisany i zaprezentowany. Rekruter, tech lead czy klient nie ma czasu domyślać się, co się działo na sali o 3:00 w nocy. Wszystko musi być czytelne z Twojego portfolio, GitHuba i slajdów.

Pierwsze 48 godzin po hackathonie: co zrobić, zanim emocje opadną

Porządkowanie kodu i repozytorium tuż po wydarzeniu

Największy błąd po hackathonie to odłożenie projektu „na później”. Po tygodniu zapominasz szczegóły, po miesiącu nie pamiętasz już nawet, jak uruchomić backend. Dlatego najlepiej w ciągu pierwszych 24–48 godzin zrobić szybki porządek:

• sprawdź, czy cały kod jest w jednym repozytorium (albo sensownie rozdzielony na front/back),
• usuń pliki tymczasowe, logi, śmieci po buildach,
• przenazwij oczywiste „tmp”, „test123”, „newfile.js” na coś zrozumiałego,
• dodaj prostą instrukcję uruchomienia w README, nawet jeśli to tylko kilka linijek.

Na tym etapie nie chodzi o perfekcyjną architekturę. Bardziej o to, by ktoś inny mógł w ogóle projekt uruchomić i zobaczyć demo bez pisania do Ciebie na LinkedInie z pytaniem „jak to odpalić?”.

Spisanie krótkiej historii projektu „na świeżo”

Drugu krok to zapisanie kontekstu, zanim uleci z pamięci. Otwórz dowolny edytor tekstu i zanotuj:

• jaki problem rozwiązywaliście,
• jakie były ograniczenia (czas, technologia, narzucone API, temat),
• jak wyglądał skład zespołu i Twoja rola,
• co działa, a co jest tylko „na pokaz” (np. zasymulowane dane).

Ten „brudnopis” później przerobisz na profesjonalny opis projektu w portfolio i README. Dzięki temu unikniesz luk w stylu: „eee… chyba używaliśmy Mongo, ale nie pamiętam dlaczego”.

Ustalenie z zespołem, co dalej z projektem

Portfolio to nie tylko kwestia techniczna, ale też organizacyjna. Jeśli pracowałeś w zespole, ustalcie od razu:

• czy repozytorium będzie prywatne czy publiczne,
• kto będzie właścicielem głównego repo (org na GitHubie czy konto jednej osoby),
• jak podpisujecie autorstwo (np. w README i prezentacji),
• czy ktoś chce kontynuować projekt po hackathonie (i w jakiej formie).

Później trudniej dopinać tematy typu licencja, domena, dostęp do serwera czy logotyp. Kilka jasnych ustaleń od samego początku zabezpiecza wszystkich – i ułatwia Ci spokojne pokazywanie projektu w portfolio bez obaw o konflikty.

Repozytorium po hackathonie: jak zamienić „chaos na szybko” w projekt, który robi wrażenie

Struktura katalogów, która wygląda profesjonalnie

Repozytorium po hackathonie często przypomina „skrzynkę z kablami po przeprowadzce”. Twój cel: stworzyć wrażenie ogarniętego, przemyślanego projektu, nawet jeśli był pisany w 24 godziny. Dobra praktyka to uporządkowana struktura katalogów. Przykład dla aplikacji webowej:

.
├── backend/
│   ├── src/
│   ├── tests/
│   └── package.json
├── frontend/
│   ├── src/
│   ├── public/
│   └── package.json
├── docs/
│   ├── architecture.md
│   └── pitch-deck.pdf
├── .gitignore
├── README.md
└── LICENSE

Taka struktura pokazuje, że:

• oddzielasz warstwy (front/back),
• myślisz o testach (nawet jeśli na starcie jest tam tylko jeden plik),
• dbasz o dokumentację (katalog docs),
• pamiętasz o licencji.

README jako centrum dowodzenia projektem

README.md jest najważniejszym plikiem w repozytorium po hackathonie. To dokładnie to miejsce, w które zajrzy rekruter, mentor, CTO czy inny programista. Dobre README zwykle zawiera:

• krótki opis projektu: 2–3 zdania, czym jest, dla kogo i jaki problem rozwiązuje,
• zrzut ekranu lub GIF z działania aplikacji,
• instrukcję uruchomienia w kilku krokach,
• sekcję „Technologie”,
• informację o zespole i rolach,
• sekcję „Stan projektu” – co działa, a co jest w planach.

Przykładowy zarys README dla projektu po hackathonie:

# Nazwa projektu

Krótki opis: co to jest, dla kogo, jaki problem rozwiązuje.

## Demo

- Link do działającej wersji (jeśli jest)
- Link do nagrania demo (np. YouTube)
- 1–2 zrzuty ekranu

## Jak uruchomić lokalnie

### Wymagania

- Node.js >= 18
- Docker (opcjonalnie)
- Konto w zewnętrznym API (np. OpenWeather)

### Kroki

```bash
git clone ...
cd projekt
npm install
npm run dev
```

## Technologie

- React
- Node.js / Express
- PostgreSQL
- Docker

## Zespół i role

- Imię A – backend, architektura bazy
- Imię B – frontend, UI/UX
- Imię C – DevOps, CI/CD, deployment

## Stan projektu

Projekt powstał w trakcie 24-godzinnego hackathonu X.
Aktualnie:
- [x] Podstawowy CRUD
- [x] Logowanie przez Google
- [ ] Panel administracyjny
- [ ] Testy e2e

Licencja i kwestie prawne w projektach po hackathonie

Otwartość projektu w repozytorium zwiększa jego wartość w portfolio. Najprościej zadbać o to przez dodanie pliku LICENSE. Kilka popularnych opcji:

• MIT – bardzo liberalna, często wybierana w projektach open source,
• Apache 2.0 – z dodatkowymi zapisami dotyczącymi patentów,
• GPL – wymaga, by projekty pochodne także były open source.

W projektach po hackathonie najczęściej spotyka się MIT lub Apache 2.0, bo nie komplikują życia przyszłym użytkownikom. Zespół powinien wspólnie ustalić wybór licencji, zwłaszcza jeśli planujecie dalszy rozwój lub komercjalizację.

Porządek w commitach i gałęziach

Podczas hackathonu commit message typu „fix”, „final”, „final2” to norma. Po wydarzeniu warto zrobić lekkie porządki:

• usuń zbędne, nieużywane branche,
• zmerguj ważne zmiany do main/master,
• opcjonalnie zrób tag lub release z wersją „hackathon” (np. v0.1-hackathon).

Nie musisz przepisywać historii commitów, ale dobrze, jeśli główna gałąź wygląda na spójną. Potencjalny pracodawca powinien móc prześledzić rozwój projektu, a Ty – w razie potrzeby – nawiązać do konkretnych zmian podczas rozmowy technicznej.

Opis projektu w portfolio: jak opowiadać o hackathonie językiem biznesu i technologii

Struktura opisu projektu, która działa na rekruterów

Surowe repozytorium na GitHubie to za mało. W portfolio (na stronie www, w PDF-ie czy profilu na platformie) projekt po hackathonie warto opisać jak mini–case study. Przykładowa struktura:

1. Nazwa i krótki tagline – jednozdaniowe wyjaśnienie, o co chodzi.
2. Problem i kontekst – 2–3 akapity o tym, dlaczego to ma sens.
3. Rozwiązanie – opis funkcjonalności i sposobu działania.
4. Technologie i stack – konkretnie, bez marketingowych ogólników.
5. Twoja rola – co dokładnie zrobiłeś, najlepiej z przykładami.
6. Efekty i rezultat – wynik hackathonu i działające elementy.
7. Nauka i dalsze plany – czego się nauczyłeś, co rozwinąłeś później.

Taki opis pozwala czytającemu szybko przejść z poziomu „o, kolejny projekt z hackathonu” do „rozumiem, co to robi, widzę technologię i wiem, jakie kompetencje potwierdza”.

Język opisu: połączenie biznesu z technikaliów

Opis projektu po hackathonie musi być zrozumiały zarówno dla HR, jak i dla senior developera. Dobry sposób to prowadzenie historii w dwóch warstwach:

• najpierw prosty język: problem użytkownika, kontekst, korzyść,
• potem konkrety techniczne: architektura, technologie, trudności techniczne.

Przykład fragmentu opisu w portfolio:

„Stworzyliśmy prototyp platformy, która pomaga małym sklepom lokalnym zarządzać zamówieniami online z kilku kanałów (strona, social media, telefon). Celem było zmniejszenie chaosu i liczby pomyłek w zamówieniach.”

Następnie zejście w technikalia:

„Zaprojektowałem i zaimplementowałem backend w Node.js/Express z bazą PostgreSQL. Kluczowym wyzwaniem było zaprojektowanie modelu danych pozwalającego na łączenie zamówień z różnych kanałów w jedną kolejkę oraz obsłużenie konfliktów statusów (np. anulacja zamówienia w jednym kanale).”

Pokazywanie własnego wkładu w projekcie zespołowym

Najtrudniejszy element przy projektach z hackathonu: jak uczciwie pokazać swój udział. Typowe błędy:

• opis „zrobiliśmy” bez wyjaśnienia „co ja zrobiłem”,
• przypisywanie sobie wszystkiego, ignorując wkład zespołu,
• zbyt ogólny opis w stylu „pomagałem przy frontendzie”.

Lepsze podejście:

• podkreślenie roli: „Fullstack developer”, „Backend developer”, „Product owner”,
• wymienienie kluczowych zadań, które były po Twojej stronie,
• odniesienie się do konkretnych commitów/plików w repozytorium.

Przykład poprawnego opisu roli:

„Jako backend developer odpowiadałem za:

• projekt schematu bazy PostgreSQL (tabele: orders, channels, customers),
• implementację endpointów REST do zarządzania zamówieniami,
• integrację z zewnętrznym API kuriera (DHL) oraz obsługę błędów po stronie API.”

Taki opis da się łatwo zweryfikować spojrzeniem w repozytorium i commits. Na rozmowie możesz pokazać konkretne fragmenty kodu i opowiedzieć o decyzjach projektowych.

Przykładowa tabela opisu projektu w portfolio

Część osób lubi ujednolicone opisy projektów w formie tabeli. Taki format sprawdza się na stronie „Projekty” lub w CV w PDF. Przykład:

Prezentacja projektu: pitch, który działa także długo po hackathonie

Jak zhackować slajdy z hackathonu na potrzeby portfolio

Dopasowanie pitch decka do odbiorcy po hackathonie

Slajdy, które działały o 3:00 w nocy przed jury, zwykle wymagają lekkiego remontu, zanim trafią do portfolio. Inny akcent przyda się dla rekrutera IT, inny dla CTO, a jeszcze inny dla potencjalnego klienta. Dlatego dobrze mieć 2–3 warianty tej samej prezentacji:

• wersję „rekrutacyjną” – skupioną na roli, technologii i procesie wytwarzania,
• wersję „biznesową” – podkreślającą problem, rynek, korzyści i model działania,
• wersję „techniczno–architektoniczną” – z diagramami, decyzjami technicznymi i kompromisami.

To wciąż ten sam projekt, ale inaczej opowiedziany. Do portfolio możesz dołączyć link do jednego PDF-a, a w repozytorium – katalog /docs/pitch/ z różnymi wariantami.

Kluczowe slajdy, które wspierają Twoje portfolio

Hackathonowe prezentacje bywają naszpikowane żargonem i żartami z sali. W wersji „portfolio” lepiej oprzeć się na kilku osiach, które świetnie grają podczas rozmów rekrutacyjnych:

1. Problem / Insight – jeden, maksymalnie dwa slajdy z konkretnym bólem użytkownika.
2. Rozwiązanie – zrzuty ekranu, krótkie opisy kluczowych use case’ów.
3. Architektura – prosty diagram (boxy + strzałki), bez „enterprise’owych” ozdobników.
4. Technologie – uporządkowana lista z krótkim uzasadnieniem wyboru (dlaczego właśnie to).
5. Twoja rola – osobny slajd: odpowiedzialności, decyzje, które przeszły przez Twoje ręce.
6. Rezultat i wnioski – co działa, co nie wyszło, co zmieniłbyś dzisiaj.

Taka prezentacja nie jest tylko „slajdami z hackathonu”. Staje się narzędziem, którym możesz podeprzeć się w trakcie rozmowy – zrekrutować sobie czas rozmówcy.

Jak łączyć demo live, nagranie i slajdy

Projekt po hackathonie prezentuje się najlepiej w trzech warstwach: demo live, nagranie wideo oraz pitch deck. Każda z nich ma trochę inne zadanie.

• Demo live – pokazujesz na rozmowie rekrutacyjnej lub podczas spotkania 1:1 na Zoomie. Tu liczy się stabilność i prosty scenariusz kliknięć, który pokaże sedno projektu w 2–3 minuty.
• Nagranie wideo – link w portfolio / README. Nawet krótki screen recording z komentarzem głosowym pokazuje, że projekt faktycznie działał.
• Slajdy – kontekst, decyzje, proces. Służą jako uzupełnienie, nie zamiast działającej aplikacji.

Dobry schemat: podczas rozmowy zaczynasz od 1–2 slajdów (problem + architektura), przechodzisz do krótkiego demo, a na koniec wracasz do slajdu o swojej roli i wnioskach.

Scenariusz krótkiego pitchu technicznego

Po hackathonie możesz dostać pytanie w stylu: „Proszę mi opowiedzieć o jednym projekcie, z którego jest Pan/Pani zadowolony/a”. Wtedy przydaje się gotowy, 90–sekundowy pitch oparty na tym samym szkielecie, co Twoja prezentacja.

Przykładowy schemat:

1. 1–2 zdania o problemie – „Zrobiliśmy X, by rozwiązać Y dla grupy Z”.
2. 2–3 zdania o rozwiązaniu – główne funkcjonalności, jak użytkownik z nich korzysta.
3. technologia – kluczowe elementy stacku + po co ich użyliście.
4. Twoja rola – najważniejsze zadania po Twojej stronie.
5. wyzwanie techniczne – jedno dobrze opowiedziane utrudnienie i jak je pokonaliście.
6. efekt – działający element, nagroda, feedback od mentorów, kontynuacja po hackathonie.

Taki pitch możesz zapisać w notatkach razem z linkami do repo i prezentacji. Po kilku miesiącach od hackathonu szczegóły łatwo wylatują z głowy, a tu chodzi o spójność i konkrety.

Minimalna jakość wizualna slajdów

Nie musisz być grafikiem, ale kilka prostych zasad od razu poprawia odbiór:

• jeden font, dwa rozmiary – nagłówek + treść, bez kombinowania z pięcioma krojami pisma,
• maksymalnie 3 kolory – tło, kolor akcentu i kolor tekstu,
• duże zrzuty ekranu – lepszy jeden czytelny screen niż kolaż mikroskopijnych miniaturek,
• minimum tekstu – slajd to punkty zaczepienia, rozwinięcie można powiedzieć albo dopisać w dokumencie obok.

Przy prezentacjach osadzonych w repozytorium sensownym kompromisem jest prosty szablon w Google Slides/Canvie, zapisany jako PDF – stabilny, lekkim linkiem do podpięcia w README.

Osobista narracja wokół kilku projektów z hackathonów

Jeśli masz za sobą więcej niż jeden hackathon, projekty warto połączyć spójną historią. Zamiast wymieniać trzy podobne aplikacje w kolejności chronologicznej, możesz podkreślić, jak zmieniała się Twoja rola i poziom trudności technicznej.

Przykładowy układ opisu w portfolio:

• Hackathon A – „pierwszy kontakt z pracą w zespole, pierwsze API, skupienie na frontendzie”.
• Hackathon B – „pierwsza odpowiedzialność za backend i architekturę, integracja z zewnętrznym serwisem”.
• Hackathon C – „rola lidera technicznego, podział zadań, CI/CD i wydanie produkcyjne na czas”.

Rekruter widzi wtedy nie tylko listę projektów, ale przede wszystkim trajektorię rozwoju. Łatwiej mu przewidzieć, jak odnajdziesz się w zespole projektowym w pracy.

Jak wybierać projekty hackathonowe do portfolio

Nie każdy projekt z hackathonu musi trafić na stronę „Projekty”. Lepiej pokazać 2–3 dopracowane przykłady niż 8 niedokończonych repozytoriów. Przy selekcji pomocne są trzy proste kryteria:

1. Stopień zgodności z celem zawodowym – jeśli celujesz w backend, pokaż projekt, w którym robiłeś logikę i model danych, nawet jeśli graficznie wypada gorzej.
2. Poziom technicznego wyzwania – integracje, nietrywialne algorytmy, ciekawa architektura. Proste CRUD-y można zgrupować w jednym akapicie.
3. Możliwość pokazania procesu – czy z repozytorium i opisu da się odczytać drogę: decyzje, kompromisy, iteracje, a nie tylko efekt końcowy.

Czasami dobrym ruchem jest połączenie dwóch mniejszych hackathonów w jedną sekcję „Eksperymenty front-endowe” albo „Projekty IoT z hackathonów” – wtedy unikniesz rozmycia uwagi odbiorcy.

Rozsądne „doszlifowanie” kodu po hackathonie

Po wydarzeniu część osób odczuwa pokusę przepisywania wszystkiego od zera tylko po to, by móc się tym pochwalić. Z perspektywy portfolio często lepiej zainwestować kilka godzin w:

• dodanie podstawowych testów (np. jednostkowych dla kluczowych funkcji),
• uporządkowanie struktury katalogów i nazw plików,
• wyciągnięcie konfiguracji do .env i dodanie przykładowego .env.example,
• usunięcie typowo „hackathonowych” skrótów (hardkodowane tokeny, dane testowe w kodzie).

Taka kosmetyka sygnalizuje, że rozumiesz różnicę między code jamem a projektem, który ktoś faktycznie może uruchomić i rozwijać.

Opis kompromisów technicznych jako atut

Projekt robiony w 24 godziny siłą rzeczy pełen jest skrótów. Udawanie, że wszystko jest „produkcyjne”, zwykle wypada sztucznie. Lepiej nazwać rzeczy po imieniu i pokazać, że świadomie wybierałeś kompromisy.

Przykłady sformułowań, które dobrze działają w README i w portfolio:

• „Ze względu na ograniczony czas zrezygnowaliśmy z osobnego serwisu autoryzacji i zastosowaliśmy proste JWT z jednym kluczem. W wersji produkcyjnej rozdzieliłbym usługę auth i wprowadził rotację kluczy.”
• „Front powstał w jednym repo bez podziału na moduły. Gdybym miał dodatkowe 2–3 dni, wydzieliłbym warstwę komponentów współdzielonych i wprowadził Storybook.”

Takie zdania pokazują sposób myślenia, a dla wielu rekruterów jest to cenniejsze niż sam stan kodu.

Łączenie repozytorium, opisu i prezentacji w jednym miejscu

Im mniej klikania po linkach, tym większa szansa, że ktoś naprawdę wejdzie w Twój projekt. Dobrym rozwiązaniem jest prosty „hub” projektu – osobna podstrona lub dokument, który zbiera wszystko:

• krótki opis projektu (problem + rozwiązanie),
• link do repozytorium,
• link do wersji demo / nagrania,
• link do prezentacji (PDF),
• 2–3 zdania o Twojej roli + wyzwanie techniczne, z którego jesteś najbardziej dumny.

Taki hub możesz podlinkować w CV jednym URL-em, zamiast rozrzucać osobno GitHuba, YouTube i Slides. Z perspektywy osoby przeglądającej dziesiątki kandydatów to duże ułatwienie.

Jak reagować na pytania o „niedokończony” projekt

Na rozmowie bardzo często pojawia się temat: „Widzę, że projekt zatrzymał się na wersji hackathonowej. Dlaczego?”. Zamiast się tłumaczyć, lepiej pokazać, czego ten projekt Cię nauczył i gdzie tę wiedzę wykorzystałeś później.

Przykładowa odpowiedź może wyglądać tak:

„Po hackathonie ustaliliśmy w zespole, że nie będziemy dalej rozwijać projektu komercyjnie. Natomiast zaadaptowałem wzorzec integracji z zewnętrznym API i podejście do logowania zdarzeń w kolejnym projekcie, który już rozwijałem samodzielnie – mogę pokazać w repo X.”

Wtedy projekt z hackathonu staje się etapem w procesie, a nie martwym bytem z jednorazowego wydarzenia.

Dokumentowanie procesu pracy nad projektem

Oprócz kodu i slajdów dobrze działa także krótka, tekstowa retrospektywa. To może być prosty plik POSTMORTEM.md w repo lub sekcja „Wnioski” w opisie portfoliowym. Kilka krótkich punktów wystarczy:

• co zadziałało dobrze (np. podział zadań, wybór technologii),
• co spowalniało (np. brak wspólnego standardu commitów, zbyt późne ustalenie zakresu MVP),
• co zmieniłbyś w kolejnym hackathonie lub projekcie zespołowym.

Takie mini–postmortem robi wrażenie na osobach technicznych – pokazuje, że umiesz myśleć procesowo, nie tylko „wrzucać kod na GitHuba”.

Przenoszenie doświadczeń z hackathonu do „prawdziwych” projektów

Ostatni krok to świadome przełożenie tego, czego nauczyłeś się na hackathonie, na kolejne repozytoria. Możesz to pokazać w portfolio przez krótkie łączniki między projektami, np.:

• „Po projekcie OrderFlow przeniosłem podejście do walidacji danych na backendzie do aplikacji X (link).”
• „Moduł powiadomień z hackathonu stał się bazą do biblioteki, którą rozwinąłem później jako osobny projekt open source (link).”

Rekruter widzi wtedy ciągłość: hackathon nie jest jednorazowym fajerwerkiem, tylko elementem ścieżki, który realnie wpływa na kolejne projekty w Twoim portfolio.

Jak pokazywać projekt z hackathonu w CV i LinkedIn

Dobrze opisany projekt w portfolio to jedno, ale wiele osób „gubi” go na etapie CV i profilu LinkedIn. Tam liczy się kilka detali, które zdecydują, czy ktoś w ogóle kliknie w link do repozytorium.

W CV projekt z hackathonu możesz wrzucić do sekcji „Projekty” albo – jeśli masz ich więcej – stworzyć osobny blok „Projekty z hackathonów”. Klucz to zwięzłość:

• nazwa projektu + wydarzenie – np. „OrderFlow – hackathon XYZ (2023)”,
• 1 zdanie o problemie – „aplikacja do optymalizacji zamówień w małej gastronomii”,
• technologie – w formie krótkiej listy: Node.js, PostgreSQL, React, Docker,
• Twoja rola – „backend + integracja z API operatora płatności”,
• 1 wynik – „demo działające na Heroku” albo „II miejsce / wyróżnienie mentorskie”.

Ten sam projekt na LinkedIn możesz opisać w sekcji „Projekty” lub pod konkretnym doświadczeniem (np. „Aktywności dodatkowe”). Dobrym zabiegiem jest wrzucenie krótkiego posta w czasie zbliżonym do hackathonu, a potem podlinkowanie go w opisie projektu. Dla rekrutera to dodatkowe źródło: widać, jak komunikujesz się publicznie, jak mówisz o swojej pracy.

Przy linkowaniu trzymaj się jednego schematu. Przykładowo:

• w CV – link do „huba” projektu (jedna strona z odnośnikami),
• na LinkedIn – ten sam link + pinned post z krótkim opisem i screenem.

Rozjechane adresy URL i różne nazwy tego samego projektu wprowadzają chaos. Spójność podnosi wiarygodność, szczególnie gdy po kilku miesiącach sam musisz szybko się w tym odnaleźć.

Repozytorium a projekt zespołowy – jak pokazać swój realny wkład

W hackathonowych repozytoriach największym problemem przy rekrutacji bywa ustalenie, co naprawdę było po Twojej stronie. Rozmówcy nie chcą odgadywać z historii commitów, czy pisałeś logikę aplikacji, czy zajmowałeś się głównie stylowaniem.

Najprościej uprościć życie wszystkim – dodać sekcję „Zespół i podział pracy” w README lub w opisie w portfolio. W kilku punktach wyłuszczasz:

• kto był w zespole i jakie role pełnił,
• za które moduły czy obszary odpowiadałeś bezpośrednio,
• co współtworzyłeś, a do czego tylko dorzucałeś drobne poprawki.

Przykład takiej sekcji:

## Zespół i podział pracy
- Anna – UX/UI, prototyp w Figma, testy z użytkownikami
- Bartek – backend (API w Node.js, integracja z API płatności, logowanie błędów)
- Ja – frontend (React, routing, formularze), wdrożenie na Vercel, konfiguracja CI

Jeśli chcesz pójść krok dalej, w opisie projektu w portfolio możesz podlinkować konkretne katalogi lub pliki, które najlepiej pokazują Twoją pracę, np. „Moduł X (link do folderu /src/modules/notifications)” albo „Konfiguracja pipeline’u (link do .github/workflows/ci.yml)”. Osoba techniczna od razu trafia w sedno zamiast przeklikiwać się przez cały kod.

Samodzielne forki i odgałęzienia projektu

Zdarza się, że po hackathonie zespół się rozchodzi, a Ty chcesz rozwinąć pewien fragment dalej w swoim tempie. To dobry materiał do portfolio, o ile jasno pokazujesz relację między oryginalnym repo a jego „gałęzią”.

Przejrzysty model może wyglądać tak:

• repo zespołowe – zachowane w oryginalnej formie, z dopiskiem w README, że kod przedstawia stan z czasu hackathonu,
• Twój fork – osobne repo (lub prywatny fork), gdzie dopisujesz rozwinięcie: refaktor, testy, nowy moduł, inne technologie.

W opisie projektu na stronie portfolio możesz wtedy napisać wprost:

„Podstawowa wersja powstała na hackathonie XYZ (link do repo zespołowego). Po wydarzeniu rozwinąłem moduł notyfikacji jako osobny mini–projekt, dopisując testy integracyjne i integrację z innym dostawcą e-mail (link do mojego repo).”

Dzięki temu nie zabierasz zespołowi „wspólnego” dorobku, a równocześnie wyraźnie pokazujesz swój indywidualny wkład i dalszy rozwój projektu.

Przygotowanie wersji demo, która przetrwa dłużej niż tydzień

Efekt „działało tylko na scenie” jest zabójczy dla portfolio. Demo z hackathonu często stoi na darmowym, tymczasowym hostingu, który po kilku tygodniach znika. Lepiej od razu pomyśleć o stabilniejszym rozwiązaniu.

Kilka opcji, które zwykle się sprawdzają:

• statyczny frontend – GitHub Pages, Netlify lub Vercel wystarczą do pokazania interfejsu, nawet jeśli backend już nie działa,
• demo „read-only” – zamiast pełnej funkcjonalności wystarczy wersja z zasymulowanymi danymi (mocki) i ograniczonymi akcjami,
• nagranie screencastu – szybki walkthrough 3–5 minut, wrzucony na niepubliczny link w serwisie video.

Dobrą praktyką jest zrobienie w README wyraźnej sekcji:

## Demo

1. Wersja online (aktualny build frontendu): https://...
2. Krótkie nagranie działania aplikacji: https://...
3. Instrukcja lokalnego uruchomienia backendu: patrz sekcja "Development"

Dzięki temu, nawet jeśli po roku backend przestanie się uruchamiać na darmowym serwerze, osoba rekrutująca wciąż ma punkt odniesienia w postaci screencastu oraz prostego frontu działającego w przeglądarce.

Segmentowanie projektów na poziomie zaawansowania

Przy kilku hackathonach z rzędu projekty potrafią się zlewać w jedną masę: „apka X w React”, „apka Y w React”, „apka Z w React + Node”. Żeby uniknąć wrażenia powtarzalności, możesz ułożyć je w portfolio warstwowo – jako etapy rozwoju.

Praktyczny podział wygląda np. tak:

• Poziom 1 – pierwsze hackathony – nacisk na podstawy: praca w zespole, integracja frontu z jednym API, ogarnięcie Git-a,
• Poziom 2 – świadome decyzje techniczne – projekty z decyzjami architektonicznymi, optymalizacją, dbałością o strukturę repo,
• Poziom 3 – quasi–produkcyjne podejście – projekty z CI/CD, testami, monitoringiem lub sensownym deploymentem.

Przy każdym poziomie wybierasz jeden główny projekt–reprezentanta, a resztę wymieniasz jedynie w jednym akapicie jako tło, np.: „Na kolejnych dwóch hackathonach rozwijałem podobny stack (React + Node), ale skupiłem się na…”. To pozwala pokazać rozwój bez przytłaczania rekrutera listą dziesięciu bardzo podobnych repozytoriów.

Balans między „ładnie wygląda” a „dużo się nauczyłem”

Częsty dylemat: pokazać projekt, który wizualnie prezentuje się świetnie, ale technicznie jest prosty, czy ten, który wygląda topornie, za to w środku siedzi ciekawy kod? Rozwiązaniem jest jasne rozróżnienie roli każdego projektu w portfolio.

Można przyjąć prosty podział ról:

• projekt–magnes – wizualnie dopieszczony, dobry do pierwszego wrażenia, screenów i prezentacji,
• projekt–argument techniczny – z mocniejszą logistyką backendu, integracjami, wydajnością czy automatyką,
• projekt–story – wokół którego da się opowiedzieć ciekawą historię o procesie, roli lidera, porażkach i wnioskach.

Często jeden projekt da się „obsadzić” w dwóch z tych ról, ale rzadko we wszystkich trzech. W portfolio możesz to zakomunikować wprost w jednym zdaniu przy opisie: „Najważniejszy dla mnie technicznie” albo „Najlepiej pokazuje współpracę w zespole”. Dzięki temu rozmówca wie, czego się po nim spodziewać.

Jak wykorzystywać slajdy projektowe poza hackathonem

Prezentacja przygotowana na demo końcowe nie musi skończyć w zapomnianym folderze. Drobne przeróbki wystarczą, by użyć jej w kilku innych kontekstach.

Kilka praktycznych zastosowań:

• krótki deck do rozmów rekrutacyjnych – 4–6 slajdów ze screenami i jednym slajdem „rola + technikalia”,
• materiał na lightning talk – 5–10-minutowa prezentacja do meetupu / wewnętrznego spotkania w firmie,
• wizualne uzupełnienie portfolio – kilka kluczowych slajdów jako obrazy w opisie projektu (np. w statycznym portfolio na GitHub Pages).

Żeby takie slajdy „żyły” dłużej, dobrze jest mieć uniwersalną, pozbawioną logotypów sponsorskich wersję prezentacji. Jedna wersja „pod hackathon” (z wymaganymi logotypami i sponsorami), druga – „portfolio ready”, bardziej neutralna. To szczegół, który pozwala uniknąć niezręczności przy publicznym dzieleniu się deckiem po kilku latach.

Checklist do szybkiego ogarnięcia projektu po hackathonie

Zamiast za każdym razem zastanawiać się od zera, co poprawić, można potraktować każdy projekt z hackathonu jak mały „pakiet porządkowy”. Daje się to zamknąć w prostą checklistę na 1–2 wieczory pracy.

Przykładowy zestaw kroków:

1. README – opis problemu, rozwiązania, technologii, roli, demo + link do prezentacji,
2. uruchamialność – plik .env.example, instrukcja lokalnego uruchomienia, poprawka oczywistych bugów blokujących start,
3. struktura repo – sensowny podział katalogów, usunięcie śmieci (zduplikowane pliki, tymczasowe szkice, stare buildy),
4. minimalne testy – choćby 2–3 testy dla kluczowych funkcji lub endpointów,
5. postmortem – krótka sekcja „Wnioski” w README (What went well / What didn't),
6. hub projektu – jedna strona lub dokument spisujący linki: repo, demo, prezentacja, nagranie, notatki.

Po takim „serwisie” projekt nadaje się do linkowania z CV bez wymówek. Nawet jeśli kod nie jest idealny, osoba oglądająca repo widzi, że dbasz o podstawową higienę techniczną i komunikację.

Włączanie hackathonów w długofalowy plan rozwoju

Same w sobie hackathony nie zbudują kariery, ale mogą być bardzo wygodnymi kamieniami milowymi. Każdy projekt możesz potraktować jako pretekst do wejścia w nową technologię, narzędzie czy rolę, zamiast powielać ciągle te same schematy.

Przykładowe podejście planistyczne:

• hackathon 1 – skupienie na podstawowej pracy zespołowej, Git, komunikacja commitów,
• hackathon 2 – przejęcie odpowiedzialności za backend / architekturę,
• hackathon 3 – wprowadzenie CI/CD i sensownego deploymentu,
• hackathon 4 – rola lidera technicznego, planowanie zadań, podejście „tech lead”,
• hackathon 5 – eksperyment z nowym stackiem lub obszarem (np. ML, devops, IoT).

Takie rozłożenie akcentów ułatwia później składanie w portfolio spójnej historii: nie „byłem na pięciu hackathonach”, tylko „stopniowo przejmowałem coraz większą odpowiedzialność i poszerzałem zakres kompetencji”. A to już język, na który wiele zespołów projektowych w firmach jest szczególnie wyczulonych.

Najczęściej zadawane pytania (FAQ)

Jak wykorzystać projekt z hackathonu w portfolio programisty?

Najważniejsze jest uporządkowanie projektu po wydarzeniu i pokazanie go w sposób zrozumiały dla rekrutera. Zadbaj o czytelne repozytorium na GitHubie (struktura katalogów, README, licencja) oraz opis projektu w portfolio w formie krótkiego case study: jaki problem rozwiązujecie, jakie technologie wykorzystałeś i jaka była Twoja rola.

Dobrą praktyką jest też dodanie linku do demo (hostowana aplikacja lub nagranie wideo), kilku zrzutów ekranu oraz sekcji „Stan projektu”, w której jasno napiszesz, co faktycznie działa, a co jest tylko prototypem.

Co zrobić z kodem w pierwszych 48 godzin po hackathonie?

W ciągu 24–48 godzin po hackathonie warto szybko uporządkować repozytorium, zanim zapomnisz szczegóły. Upewnij się, że cały kod jest w jednym miejscu, usuń pliki tymczasowe i logi, popraw nazwy plików typu „tmp” czy „test123” na bardziej opisowe oraz dodaj prostą instrukcję uruchomienia w README.

Równolegle zapisz „na brudno” historię projektu: problem, który rozwiązywaliście, ograniczenia, skład zespołu, swoją rolę i informacje, co jest faktycznie zaimplementowane, a co zasymulowane. Ten szkic później przerobisz na profesjonalny opis.

Jak powinno wyglądać dobre README po hackathonie?

README po hackathonie powinno pełnić rolę centrum dowodzenia projektu. Umieść w nim: krótki opis (co to jest i dla kogo), sekcję z demo (link do aplikacji, nagranie, screeny), instrukcję uruchomienia krok po kroku, listę użytych technologii, informacje o zespole i rolach oraz sekcję „Stan projektu” z listą zrobione / w planach.

Zadbaj, aby ktoś z zewnątrz mógł na podstawie samego README zrozumieć ideę projektu, uruchomić go lokalnie i zobaczyć kluczowe funkcje, bez konieczności kontaktowania się z Tobą po dodatkowe instrukcje.

Jak opisać projekt z hackathonu w portfolio, żeby zainteresować rekrutera?

Najlepiej potraktować opis projektu jak mini case study. Zacznij od nazwy i krótkiego tagline’u, potem opisz problem i kontekst, który adresuje wasze rozwiązanie. Następnie przedstaw, jak działa aplikacja (kluczowe funkcjonalności) i w jakim stacku technologicznym ją zrobiliście.

Osobno podkreśl swoją rolę: konkretne zadania (np. „zaprojektowałem model bazy danych”, „przygotowałem integrację z zewnętrznym API”) oraz efekty (co udało się dowieźć w trakcie hackathonu, jakie były wyniki). Na końcu możesz dodać, czego się nauczyłeś i czy projekt był dalej rozwijany.

Jak uporządkować repozytorium po hackathonie, żeby wyglądało profesjonalnie?

Zacznij od przejrzystej struktury katalogów, np. osobno frontend/, backend/, docs/, plus pliki takie jak .gitignore, README.md i LICENSE w katalogu głównym. W docs/ możesz dodać prosty opis architektury i pitch deck z prezentacji z hackathonu.

Następnie posprzątaj gałęzie i commity: usuń nieużywane branche, zmerguj istotne zmiany do głównej gałęzi i opcjonalnie oznacz wersję z hackathonu tagiem (np. v0.1-hackathon). To pokaże, że potrafisz pracować z Gitem w uporządkowany sposób.

Jaką licencję wybrać dla projektu z hackathonu na GitHubie?

W większości projektów po hackathonie dobrze sprawdzają się licencje MIT lub Apache 2.0, bo są proste i przyjazne dla przyszłych użytkowników oraz potencjalnych kontrybutorów. MIT jest bardzo liberalna, Apache 2.0 dodatkowo reguluje kwestie patentowe, a GPL wymaga, by projekty pochodne również były open source.

Decyzję o licencji warto podjąć w zespole, szczególnie jeśli myślicie o dalszym rozwoju lub komercjalizacji projektu. Po wyborze dodaj plik LICENSE do repozytorium i wspomnij o licencji w README.

Czy warto rozwijać projekt po hackathonie, jeśli ma służyć tylko do portfolio?

Nawet jeśli projekt ma być głównie elementem portfolio, warto poświęcić trochę czasu na dopracowanie kluczowych elementów: stabilne demo, poprawki najgorszych „skrótów na czas” w kodzie, kilka testów podstawowych funkcji i solidny opis. To często wystarczy, by projekt wyglądał jak przemyślany prototyp, a nie jednorazowy „proof of concept”.

Jeśli masz przestrzeń, możesz dodać jedną–dwie funkcje, które pokażą Twój rozwój po hackathonie (np. lepsze logowanie, prosty monitoring, sensowniejszy deployment). W portfolio podkreśl wtedy, które elementy powstały na wydarzeniu, a co dobudowałeś później.

Kluczowe obserwacje

• Sam udział w hackathonie nie buduje portfolio – kluczowe jest uporządkowanie projektu po wydarzeniu: repozytorium, opis, prezentacja, case study.
• Portfolio po hackathonie jest mocnym atutem, bo pokazuje pracę pod presją, współpracę w zespole, realny problem oraz pełny przepływ od pomysłu do demo.
• Pierwsze 24–48 godzin po hackathonie trzeba przeznaczyć na porządek w kodzie i repozytorium: usunięcie śmieci, sensowne nazwy plików i podstawowe README z instrukcją uruchomienia.
• Warto jak najszybciej spisać historię projektu – problem, ograniczenia, skład zespołu, swoją rolę i stan funkcjonalności – by później stworzyć rzetelny opis do portfolio.
• Niezbędne są jasne ustalenia z zespołem: status repozytorium (publiczne/prywatne), właściciel, sposób oznaczania autorstwa, plany rozwoju i kwestie licencji.
• Profesjonalnie uporządkowana struktura katalogów (np. osobno backend, frontend, tests, docs, LICENSE) buduje wrażenie przemyślanego projektu, nawet jeśli powstał w 24 godziny.
• README jest centrum dowodzenia projektem i powinno zawierać opis, demo, instrukcję uruchomienia, technologie, skład zespołu oraz jasny stan projektu (co działa, co jest w planach).