Portfolio programisty w 2026 - strona, która działa jak CV, sprzedaje freelance i buduje markę osobistą

Rekruterka ma otwartych trzydzieści zakładek. Właśnie przeszła przez stos CV na to samo stanowisko - Senior Backend Developer, Python. Twoje CV wygląda tak samo jak pozostałe dwadzieścia dziewięć - te same sekcje, ten sam układ z szablonu Canva, ta sama lista "umiejętności: Python, Django, PostgreSQL, Docker" bez kontekstu. Ma piętnaście sekund, żeby zdecydować, czy otworzy je jeszcze raz po pierwszym przejrzeniu. Nie otwiera.

Dwa biurka dalej ten sam proces przechodzi CV kogoś innego. Rekruterka klika link na dole dokumentu - "portfolio: jankowalski.dev" - i ląduje na stronie, która w dziesięć sekund pokazuje więcej niż CV pokazałoby w dziesięć minut. Trzy projekty, każdy z jednym zdaniem o problemie i jednym zdaniem o efekcie. Stack technologiczny widoczny od razu, nie jako lista, tylko jako kontekst przy każdym projekcie. Link do repo, gdzie kod rzeczywiście wygląda tak, jak deklaruje CV. Rekruterka spędza na tej stronie dziewięćdziesiąt sekund - sześć razy dłużej niż na samym dokumencie CV - i wysyła zaproszenie na rozmowę tego samego dnia.

Różnica między tymi dwoma kandydatami nie leży w umiejętnościach. Może być identyczna, a często jest odwrotna - to pierwszy kandydat bywa technicznie lepszy. Różnica leży w tym, że jeden z nich ma coś, co robi za niego pierwsze wrażenie, zanim ktokolwiek zada mu jedno pytanie, a drugi ma dokument, który wygląda identycznie jak dokument każdego innego kandydata na tym samym poziomie doświadczenia.

Ten artykuł jest o tej różnicy - a konkretnie o tym, jak zbudować własną stronę, która działa niezależnie od tego, czy szukasz dziś etatu, czy chcesz zacząć brać zlecenia jako freelancer, czy po prostu budujesz widoczność, która kiedyś się przyda. Pokazujemy konkretny szkielet takiej strony, konkretny przykład jak opisać jeden projekt, żeby zrobił robotę za Ciebie, jak to zoptymalizować pod SEO, i jakimi narzędziami to zbudować - łącznie z transparentnym wskazaniem, gdzie w tym artykule pojawia się nasze własne narzędzie.

Dlaczego sam LinkedIn i sam GitHub czasem nie wystarczają

Zanim przejdziemy do konkretów, warto uczciwie odpowiedzieć na pytanie, które nasuwa się najpierw - po co w ogóle własna strona, skoro masz już profil LinkedIn i konto GitHub. Odpowiedź nie brzmi "bo LinkedIn jest zły" - LinkedIn jest dobry i wciąż powinien być pierwszym miejscem, w którym budujesz obecność, jak pisaliśmy szerzej w naszym przewodniku o marce osobistej programisty. Problem leży gdzie indziej - w tym, że oba te profile działają w cudzym formacie, na cudzych zasadach, i cudzy algorytm decyduje o tym, co z nich w ogóle zostanie pokazane.

Profil LinkedIn ma sztywną strukturę sekcji, w której nie da się wyróżnić akurat tego projektu, który najlepiej pasuje do konkretnej rozmowy rekrutacyjnej czy konkretnego klienta. GitHub pokazuje kod, ale nie pokazuje kontekstu biznesowego tego kodu - zielona siatka commitów nie mówi rekruterowi, że ten konkretny projekt skrócił czas przetwarzania zamówień z czterech sekund do trzystu milisekund. Oba profile są też, z definicji, identyczne w formacie dla każdego użytkownika - Twój profil LinkedIn wygląda strukturalnie tak samo jak profil dziesięciu tysięcy innych programistów, różni się tylko treścią wpisaną w te same pola.

Własna strona nie ma żadnego z tych ograniczeń. Ty decydujesz, co jest na górze, co dostaje największą czcionkę, który projekt pojawia się jako pierwszy, jaki jest ton całości. To jest dokładnie ta różnica, którą widać w przykładzie z początku tego artykułu - nie w tym, że jeden kandydat ma więcej umiejętności, tylko w tym, że jeden z nich kontroluje, jak te umiejętności są prezentowane, a drugi oddał tę kontrolę formatowi CV i algorytmowi LinkedIn.

Jedna strona, trzy różne cele - i to, co je łączy

Zanim zaczniesz projektować konkretne sekcje, warto rozstrzygnąć jedną rzecz - po co dokładnie robisz tę stronę. Nie dlatego, że potrzebujesz trzech osobnych stron dla trzech różnych sytuacji, tylko dlatego, że cel decyduje o tym, co ląduje na samej górze i jakie działanie ma podjąć odwiedzający po przeczytaniu pierwszego ekranu.

W praktyce programiści budują taką stronę z trzech różnych, częściowo nakładających się powodów. Pierwszy to aktywne poszukiwanie etatu - strona działa wtedy jak rozszerzone, żywe CV, które rekruter otwiera po przejrzeniu dokumentu PDF. Drugi to sprzedaż usług jako freelancer lub kontraktor - strona działa jak strona ofertowa, z jasnym opisem tego, co robisz, dla kogo, i jak to zamówić. Trzeci to budowanie długoterminowej widoczności - marki osobistej, która nie sprzedaje niczego konkretnego dziś, ale sprawia, że za rok czy dwa lata to Ciebie ktoś znajdzie pierwszego, zanim w ogóle zacznie szukać gdzie indziej.

Dobra wiadomość jest taka, że te trzy cele dzielą ze sobą znaczną część treści - to samo portfolio projektów, ta sama historia zawodowa, te same referencje działają we wszystkich trzech kontekstach. Różnica leży głównie w jednym miejscu - w tym, co widać jako pierwsze i jakie jest główne wezwanie do działania na samej górze strony.

Cel strony	Co widać jako pierwsze	Główne CTA	Ton
Szukam etatu	Rola, poziom, stack, dostępność ("dostępny od...")	Link do CV/LinkedIn, "napisz do mnie"	Rzeczowy, konkretne liczby i zakres odpowiedzialności
Sprzedaję usługi freelance	Konkretny problem, który rozwiązujesz, dla kogo	"Umów rozmowę", cennik lub widełki	Bezpośredni, zorientowany na klienta i jego ryzyko
Buduję markę osobistą	Punkt widzenia, specjalizacja, treści (artykuły, wystąpienia)	Newsletter, obserwuj, link do treści	Eksperckie, długoterminowe, mniej transakcyjne

Praktyczna wskazówka - jeśli nie jesteś pewien, w którym trybie dziś jesteś, zacznij od trybu "szukam etatu lub kontraktu", bo to najszerszy wspólny mianownik. Większość elementów, które sprawdzają się tam, sprawdza się też w pozostałych dwóch trybach, a przejście z jednego trybu do drugiego to zwykle zmiana nagłówka i jednego zdania CTA, nie przebudowa całej strony od zera.

Uniwersalny szkielet, który działa niezależnie od celu

Niezależnie od tego, który z trzech celów jest dziś Twoim priorytetem, dobra strona portfolio programisty zbudowana jest z tego samego zestawu elementów. Różni się kolejność akcentów, nie sam zestaw.

Jedno zdanie, kim jesteś i co robisz - widoczne bez przewijania. Nie "Cześć, jestem Jan, pasjonat technologii" - tylko konkretne stanowisko i specjalizacja, np. "Backend developer specjalizujący się w systemach płatności - 6 lat doświadczenia, Python i Go". Rekruter albo klient musi wiedzieć w trzy sekundy, czy w ogóle jest tu we właściwym miejscu.

Krótka sekcja "o mnie" z jednym konkretem, nie z listą przymiotników. "Odpowiedzialny, komunikatywny, zorientowany na cel" nie mówi nic - te same trzy słowa napisze o sobie każdy inny kandydat. Zamiast tego jedno zdanie z konkretem: "Ostatnie trzy lata spędziłem budując system rozliczeń dla platformy obsługującej 40 000 transakcji dziennie" mówi więcej niż akapit przymiotników.

Trzy do pięciu projektów, nie dwadzieścia. To jeden z najczęstszych błędów, do którego wracamy w dalszej części artykułu - im więcej projektów wrzucisz, tym mniej uwagi dostaje każdy z nich. Trzy dobrze opisane projekty robią więcej niż piętnaście wrzuconych linkiem bez kontekstu.

Stack technologiczny pokazany w kontekście, nie jako chmura tagów. Zamiast osobnej sekcji z ikonkami pięćdziesięciu technologii, o których kiedykolwiek słyszałeś, pokaż stack przy każdym projekcie osobno - to od razu odpowiada na pytanie "w czym konkretnie masz doświadczenie produkcyjne", a nie "o czym kiedyś czytałeś w dokumentacji".

Dowód społeczny - opinia, referencja, logo firmy, w której pracowałeś. Jedno zdanie od byłego menedżera czy klienta ("Jan dostarczył projekt dwa tygodnie przed terminem i sam zgłosił trzy rzeczy, o których nie pomyśleliśmy") waży więcej niż dziesięć Twoich własnych zdań o sobie. Jeśli nie masz jeszcze żadnej referencji, poproś o nią teraz - jedno zdanie w wiadomości od byłego współpracownika kosztuje mniej niż pięć minut jego czasu.

Jedno, jasne działanie do podjęcia - i tylko jedno. Strona z pięcioma równorzędnymi przyciskami ("Napisz email", "Zobacz CV", "LinkedIn", "GitHub", "Umów rozmowę") rozmywa decyzję odwiedzającego. Wybierz jedno główne CTA dopasowane do celu z tabeli wyżej, resztę linków zostaw mniejszą, drugorzędną czcionką w stopce.

Kontakt bez przeszkód. Formularz kontaktowy wymagający zalogowania się przez trzecią usługę odrzuca ludzi, którzy mają dziesięć sekund między jednym a drugim spotkaniem. Zwykły mailto: link albo prosty formularz bez zbędnych pól działa lepiej niż rozbudowany system.

Jak opisać jeden projekt tak, żeby zrobił robotę za Ciebie

To jest miejsce, w którym większość stron portfolio traci najwięcej - nie w wyglądzie, tylko w treści opisu projektu. Żeby to nie zostało na poziomie ogólnej rady "opisuj konkretnie", rozpiszmy to na jednym, pełnym przykładzie - świadomie fikcyjnym, ale zbudowanym z typowych, powtarzających się wzorców, jakie widać w realnych portfoliach programistów.

Punkt wyjścia, czyli to, co dziewięć na dziesięć osób wpisuje instynktownie:

System zarządzania magazynem
Zbudowałem aplikację webową do zarządzania stanami magazynowymi. Użyłem Django i PostgreSQL, frontend w React. Aplikacja pozwala na dodawanie produktów, śledzenie stanów i generowanie raportów.

Ten opis nie jest źle napisany po polsku - jest źle napisany strategicznie. Wymienia technologie i funkcje, ale nie odpowiada na jedyne pytanie, które faktycznie interesuje rekrutera albo klienta - "dlaczego to w ogóle miało znaczenie, i jak duży był problem, zanim to powstało". Przepiszmy ten sam projekt krok po kroku.

Krok pierwszy - zacznij od problemu, nie od technologii. Zamiast "zbudowałem aplikację do zarządzania magazynem", zapytaj się, jaki konkretny ból istniał wcześniej. "Firma zarządzała stanami magazynowymi w arkuszu Excel współdzielonym przez pięć osób - średnio raz w tygodniu dochodziło do rozbieżności między stanem w arkuszu a stanem faktycznym, co prowadziło do sprzedaży produktów, których fizycznie nie było na stanie."

Krok drugi - opisz rozwiązanie jednym zdaniem, nie listą funkcji. "Zbudowałem aplikację webową w Django z synchronizacją stanów w czasie rzeczywistym, dostępną jednocześnie dla całego zespołu magazynu, z automatycznym blokowaniem sprzedaży produktu, którego stan spadł do zera."

Krok trzeci - podaj mierzalny efekt, nawet przybliżony. To jest element, którego brakuje w niemal każdym słabym opisie projektu. "Po wdrożeniu liczba rozbieżności między stanem magazynowym a faktycznym spadła z około czterech przypadków tygodniowo do zera w ciągu pierwszych trzech miesięcy działania systemu." Jeśli nie masz dokładnej liczby, bo nikt jej formalnie nie mierzył, użyj szacunku i powiedz wprost, że to szacunek - "szacunkowo skróciło to czas inwentaryzacji o połowę" wciąż mówi więcej niż brak jakiejkolwiek liczby.

Krok czwarty - dopiero teraz stack technologiczny, jako kontekst, nie jako nagłówek. "Backend: Django, PostgreSQL, Celery do zadań asynchronicznych. Frontend: React z WebSocketami do synchronizacji w czasie rzeczywistym. Wdrożone na własnej infrastrukturze klienta z CI/CD przez GitHub Actions."

Krok piąty - jeden link, który pozwala to zweryfikować. Link do repozytorium (jeśli kod może być publiczny), link do żywej wersji demo, albo - jeśli projekt jest objęty poufnością klienta - jedno zdanie wyjaśniające, dlaczego nie możesz pokazać kodu, plus ewentualny zrzut ekranu interfejsu.

Złożone razem, te pięć kroków dają opis, który w tej samej objętości mówi wielokrotnie więcej niż wersja wyjściowa:

System zarządzania magazynem - koniec rozbieżności w stanach
Firma zarządzała stanami magazynowymi w arkuszu współdzielonym przez pięć osób - średnio cztery razy w tygodniu dochodziło do rozbieżności między stanem w arkuszu a rzeczywistym, co prowadziło do sprzedaży produktów, których fizycznie nie było na stanie. Zbudowałem aplikację webową z synchronizacją stanów w czasie rzeczywistym, dostępną jednocześnie dla całego zespołu magazynu, z automatycznym blokowaniem sprzedaży produktu przy zerowym stanie. Po trzech miesiącach liczba rozbieżności spadła do zera.
Backend: Django, PostgreSQL, Celery. Frontend: React z WebSocketami. CI/CD przez GitHub Actions.
[Zobacz repozytorium] [Demo na żywo]

Ten sam wzorzec - problem, rozwiązanie jednym zdaniem, mierzalny efekt, dopiero potem stack, na końcu weryfikowalny link - powtarzalny jest niezależnie od tego, czy opisujesz projekt komercyjny, projekt open source, czy projekt zaliczeniowy z bootcampu. Różni się tylko to, skąd bierzesz liczbę w kroku trzecim - z realnych metryk klienta, z benchmarku wydajności, albo, przy braku żadnych twardych danych, z uczciwego oszacowania zakresu ("obsługiwał ruch rzędu kilku tysięcy zapytań dziennie w środowisku testowym").

SEO własnej strony - żeby znalazł Cię nie tylko ten, kto już zna Twój link

Strona portfolio, którą widzą wyłącznie ludzie, którym sam wyślesz link, robi połowę swojej roboty. Druga połowa to sytuacja, w której ktoś, kto Cię nie zna - rekruter przeglądający kandydatów po nazwisku z CV, klient szukający "freelancer Python Kraków", ktoś kto zapamiętał Twoje wystąpienie na meetupie i próbuje Cię odnaleźć po fragmencie nazwiska - trafia na Twoją stronę przez samo wyszukiwanie w Google. Kilka rzeczy realnie na to wpływa, i żadna z nich nie wymaga wiedzy SEO na poziomie eksperckim.

Tytuł strony i meta opis muszą zawierać Twoje imię i nazwisko oraz rolę, nie tylko nazwę firmy czy generyczny slogan. "Jan Kowalski - Backend Developer, Python i Django" w tagu title daje Google jasny sygnał, na jakie zapytanie ta strona odpowiada. Sama nazwa domeny czy puste "Portfolio" w tytule tego sygnału nie daje.

Własna domena z Twoim imieniem i nazwiskiem bije podstronę na cudzej platformie w wynikach wyszukiwania po nazwisku. Domena kosztuje dziś kilkadziesiąt złotych rocznie i jest jednym z najlepszych zwrotów z inwestycji, jakie można zrobić dla własnej widoczności - jankowalski.dev czy jankowalski.pl w wynikach wyszukiwania po własnym imieniu i nazwisku wygrywa niemal zawsze z podstroną w domenie generatora czy platformy typu "linktr.ee".

Dane strukturalne typu Person (schema.org) pomagają Google zrozumieć, że strona reprezentuje konkretną osobę, nie firmę czy blog. To kilka linijek kodu JSON-LD w nagłówku strony z Twoim imieniem, rolą, linkami do profili społecznościowych - nie wymaga zaawansowanej wiedzy technicznej, wystarczy gotowy szablon, który wypełnia się własnymi danymi.

Treść, nie tylko wygląd, decyduje o tym, na jakie zapytania strona się pojawi. Strona złożona wyłącznie z grafik i animacji bez tekstu odczytywalnego przez wyszukiwarkę nie ma szans zaindeksować się na żadne konkretne zapytanie - opisy projektów, sekcja "o mnie", nawet nagłówki sekcji, powinny być prawdziwym tekstem HTML, nie tekstem wypalonym w obrazku czy renderowanym wyłącznie po stronie klienta bez odpowiedniego renderowania po stronie serwera.

Szybkość ładowania ma znaczenie podwójnie - dla SEO i dla pierwszego wrażenia. Strona portfolio, która ładuje się cztery sekundy, bo zawiera niekompresowane zdjęcia w rozdzielczości aparatu, traci część odwiedzających jeszcze zanim zobaczą pierwszy nagłówek - a wolne ładowanie jest też bezpośrednim czynnikiem rankingowym w wynikach wyszukiwania.

Jakimi narzędziami to zbudować - przegląd realnych opcji

Nie ma jednej słusznej odpowiedzi na pytanie, jak technicznie zbudować taką stronę - właściwy wybór zależy od tego, ile czasu chcesz w to zainwestować, jak bardzo chcesz kontrolować każdy szczegół, i czy strona ma być jednorazowym projektem, czy czymś, co planujesz regularnie aktualizować.

Sam kod - HTML, CSS, ewentualnie prosty framework. Najlepsza opcja, jeśli sam jesteś programistą i chcesz, żeby sama strona była dodatkowym dowodem umiejętności - dobrze napisany, szybki, responsywny frontend bez zbędnych zależności mówi coś o Tobie sam w sobie. Wada - zajmuje najwięcej czasu, i łatwo wpaść w pułapkę dopieszczania animacji zamiast pisania treści, która faktycznie sprzedaje.

GitHub Pages z gotowym szablonem. Darmowy hosting, prosta konfiguracja własnej domeny, dobrze rozumiane przez rekruterów techniczne środowisko. Dobra opcja, jeśli chcesz oszczędzić czas na hostingu, ale wciąż mieć pełną kontrolę nad kodem. Wymaga jednak podstawowej znajomości Gita i budowania statycznych stron, co dla części osób poza samym programowaniem bywa dodatkowym progiem.

Notion jako publiczna strona. Zaskakująco popularna opcja wśród freelancerów, bo pozwala edytować treść bez dotykania kodu w ogóle - dobra na szybki start, słaba pod kątem SEO i pod kątem pełnej kontroli nad wyglądem. Strona w Notion zwykle wygląda tak, jak wygląda Notion, co ogranicza możliwość wyróżnienia się.

Sekcja "Featured" na LinkedIn plus PDF. Najmniejszy próg wejścia - zero dodatkowej infrastruktury, zero kosztów, ale też zero własnej domeny, zero kontroli nad wyglądem i najsłabsza opcja pod kątem SEO poza samym LinkedIn. Dobra jako uzupełnienie, słaba jako jedyne rozwiązanie.

Gotowe generatory stron portfolio. Rosnąca kategoria narzędzi robiących dokładnie to, o czym pisze ten artykuł - generują gotową stronę portfolio na podstawie CV czy kilku wprowadzonych informacji, bez pisania kodu i bez konfigurowania hostingu. Warto tu być w pełni transparentnym - jednym z takich narzędzi jest 2sh.pl - tworzenie stron internetowych bez wiedzy technicznej, produkt, który współtworzymy razem z 2hr.pl. Gotowy przykład strony portfolio programisty Python wygenerowanej tym narzędziem warto potraktować jako punkt odniesienia do struktury opisanej w tym artykule, niezależnie od tego, czy ostatecznie zdecydujesz się na to konkretne narzędzie, konkurencyjne rozwiązanie, czy własny kod od zera.

Niezależnie od wybranego narzędzia, zasady opisane wcześniej w tym artykule - konkretny opis projektu zamiast listy technologii, jedno jasne CTA, dane strukturalne, własna domena - obowiązują tak samo. Narzędzie decyduje o tym, ile czasu poświęcisz na wdrożenie, nie o tym, czy treść, którą wypełnisz, będzie dobra.

Najczęstsze błędy, które psują dobrą stronę

Szablon widoczny na pierwszy rzut oka. Rekruterzy techniczni oglądają dziesiątki podobnych stron miesięcznie - jeśli Twoja strona wygląda jak dokładnie ten sam darmowy szablon, który widzieli już dwa razy w tym tygodniu, traci część wiarygodności, zanim ktokolwiek przeczyta jedno zdanie treści. Nie trzeba budować niczego wymyślnego - wystarczy zmienić układ na tyle, żeby strona nie była kalką pierwszego wyniku z Google na "free portfolio template".

Dwadzieścia projektów zamiast trzech dobrze opisanych. Instynkt podpowiada, że więcej projektów znaczy więcej dowodów kompetencji - w praktyce działa odwrotnie. Odwiedzający, który widzi dwadzieścia kafelków z jednym zdaniem każdy, nie przeczyta żadnego uważnie. Trzy projekty opisane metodą z poprzedniej sekcji tego artykułu robią więcej niż dwadzieścia opisanych jednym zdaniem.

Nieaktualne dane kontaktowe albo status dostępności. Strona portfolio z informacją "dostępny od stycznia 2025" widziana w sierpniu 2026 roku sugeruje, że w ogóle o nią nie dbasz - co przekłada się bezpośrednio na wrażenie, że tak samo nie dbałbyś o projekt klienta czy pracodawcy.

Brak jasnego CTA, albo pięć równorzędnych CTA naraz. Opisane już wcześniej, ale warto powtórzyć, bo to jeden z najczęściej powtarzających się błędów - strona bez jasnej odpowiedzi na pytanie "co mam teraz zrobić" traci konwersję niezależnie od tego, jak dobra jest reszta treści.

Treść pisana pod rekrutera, gdy tak naprawdę szukasz klientów freelance, albo odwrotnie. Wracając do tabeli z wcześniejszej części artykułu - strona z cennikiem godzinowym i CTA "umów płatną konsultację" myli rekrutera oceniającego kandydata na etat, a strona napisana czysto pod CV bez żadnej wzmianki o dostępności do zleceń nie konwertuje potencjalnego klienta. Jeśli chcesz obsłużyć oba te przypadki na jednej stronie, potrzebujesz jasno rozdzielonej sekcji albo osobnej ścieżki dla każdego z nich, nie jednego, uniwersalnego akapitu, który próbuje mówić do wszystkich naraz.

Najczęstsze pytania o portfolio programisty

Czy potrzebuję portfolio, jeśli mam dobre CV i aktywny profil LinkedIn?

Nie jest to absolutna konieczność, ale to jedna z niewielu inwestycji czasu w poszukiwaniu pracy czy zleceń, które płacą się wielokrotnie - raz zbudowana strona pracuje na Twoją korzyść przy każdej kolejnej aplikacji, każdej kolejnej rozmowie z potencjalnym klientem, bez dodatkowego nakładu pracy. CV i LinkedIn wciąż powinny istnieć i być aktualne - portfolio jest uzupełnieniem, które pokazuje to, czego format CV pokazać nie potrafi.

Ile czasu zajmuje zbudowanie dobrej strony portfolio od zera?

Przy pisaniu własnego kodu, licząc od pustej strony do gotowej, opublikowanej wersji z trzema opisanymi projektami - realistycznie od kilku do kilkunastu godzin rozłożonych na kilka wieczorów, przy czym większość tego czasu pochłania nie sam kod czy design, tylko dopracowanie treści opisów projektów metodą opisaną wcześniej w tym artykule. Przy użyciu gotowego generatora czy szablonu ten czas skraca się zwykle do jednego, może dwóch wieczorów - ale dobre opisy projektów wciąż wymagają tego samego namysłu, niezależnie od narzędzia.

Czy portfolio ma sens dla juniora bez żadnych komercyjnych projektów?

Tak, i to często w większym stopniu niż dla seniora, który może polegać na samej reputacji i sieci kontaktów. Dla juniora portfolio może opierać się na projektach zaliczeniowych z kursu czy bootcampu, własnych projektach hobbystycznych, czy udziale w projektach open source - kluczem jest zastosowanie tej samej metody opisu: problem, rozwiązanie, efekt, dopiero potem stack, nawet jeśli "efekt" to szacunkowy zakres funkcjonalności zamiast twardej metryki biznesowej. Więcej o budowaniu pierwszego portfolio i pierwszej pracy piszemy w naszym przewodniku dla juniora szukającego pierwszej pracy.

Czy warto pokazywać widełki cenowe na stronie, jeśli szukam zleceń freelance?

To zależy od tego, jak bardzo chcesz odfiltrować klientów niedopasowanych budżetowo, zanim w ogóle napiszą pierwszą wiadomość - pokazanie orientacyjnych widełek eliminuje rozmowy, które i tak skończyłyby się na etapie wyceny, kosztem tego, że część klientów z wyższym budżetem może zakotwiczyć się na dolnej granicy widełek. Więcej o samym wycenianiu i negocjowaniu stawek jako freelancer piszemy w naszym przewodniku po freelancingu w polskim IT oraz w artykule o negocjacjach wynagrodzenia w IT.

Czy strona portfolio powinna być po polsku, po angielsku, czy w obu wersjach?

Zależy od tego, gdzie realnie szukasz pracy czy klientów. Jeśli celujesz wyłącznie w polski rynek, wersja polska w zupełności wystarczy. Jeśli bierzesz pod uwagę zlecenia zagraniczne czy rekrutację w międzynarodowych firmach obecnych w Polsce, wersja angielska - albo obie, z prostym przełącznikiem języka - poszerza realną pulę odbiorców, którzy w ogóle są w stanie przeczytać treść strony.

Jak często aktualizować taką stronę?

Wystarczy przegląd raz na kilka miesięcy, albo za każdym razem, gdy kończysz projekt na tyle znaczący, że warto go dodać zamiast najsłabszego z obecnych trzech. Częstsza aktualizacja nie jest konieczna - ważniejsze niż częstotliwość jest to, żeby informacje o dostępności i dane kontaktowe nigdy nie były nieaktualne, bo to jeden z błędów opisanych wcześniej w tym artykule, który najszybciej podważa wiarygodność całości.

Podsumowanie

Własna strona portfolio nie zastępuje CV, LinkedIn ani GitHuba - uzupełnia je w miejscu, gdzie żaden z tych formatów nie daje Ci pełnej kontroli nad tym, jak jesteś prezentowany. Niezależnie od tego, czy dziś szukasz etatu, zaczynasz brać pierwsze zlecenia jako freelancer, czy po prostu budujesz widoczność na przyszłość, ten sam szkielet działa we wszystkich trzech sytuacjach - jasne, jedno zdanie kim jesteś, kilka dobrze opisanych projektów zamiast dwudziestu wrzuconych bez kontekstu, jedno czytelne działanie do podjęcia, i podstawy SEO, które sprawiają, że strona pracuje na Twoją korzyść również wtedy, gdy nikomu sam nie wyślesz linku.

Najważniejszy, praktyczny wniosek z całego tego artykułu sprowadza się do jednego zdania metody opisanej przy przykładzie projektu magazynowego - zacznij od problemu, nie od technologii, skończ na mierzalnym efekcie, nawet jeśli to tylko szacunek. Ta jedna zmiana, zastosowana konsekwentnie do każdego projektu na stronie, robi więcej dla Twojej wiarygodności niż najlepszy szablon graficzny czy najdroższe narzędzie, którym tę stronę zbudujesz.

Transparentność: w sekcji o narzędziach wspominamy 2sh.pl - to nasz własny produkt, tworzony przez ten sam zespół co 2hr.pl. Nie jest to płatna współpraca z zewnętrznym podmiotem, tylko szczere polecenie własnego narzędzia, które naszym zdaniem rozwiązuje dokładnie problem opisany w tym artykule. Metoda opisana w tekście - konkretne opisy projektów, jedno jasne CTA, podstawy SEO - działa niezależnie od tego, jakim narzędziem, jeśli w ogóle jakimkolwiek, zdecydujesz się zbudować własną stronę.