Od etatu do freelancera IT – co się naprawdę zmienia
Freelancer vs pracownik etatowy – kluczowe różnice w codzienności
Freelancer IT, który chce zdobywać pierwsze zlecenia bez spamu i dumpingowych stawek, funkcjonuje w zupełnie innym modelu niż pracownik na etacie. Na umowie o pracę główna odpowiedzialność kończy się zazwyczaj na realizacji zadań: przydzielonych ticketów, user stories, drobnych usprawnień. Sprzedaż, marketing, negocjacje, rozliczenia, pilnowanie płatności – tym zajmują się inni. Jako wolny strzelec przejmujesz wszystkie te role naraz.
Nagła zmiana polega na tym, że programowanie przestaje być jedynym „produktem” twojej pracy. Pojawia się konieczność pozyskiwania klientów, analizowania ich potrzeb, tłumaczenia im na język biznesu, co dokładnie zrobisz i dlaczego to ma dla nich sens finansowy. Nawet jeśli masz świetne umiejętności techniczne, brak elementarnych kompetencji sprzedażowo-komunikacyjnych potrafi skutecznie zablokować start.
Na etacie, gdy kończy się projekt lub spada ilość zadań, zmartwieniem jest co najwyżej wewnętrzny „bench” albo kolejny projekt w tej samej firmie. We freelansie IT okresy bez projektów oznaczają brak przychodów. Jednocześnie to ty decydujesz, czy bierzesz wszystko jak leci, czy stawiasz granice przy wycenie, typie zleceń i współpracy. Te decyzje wpływają bezpośrednio na to, czy utrzymasz zdrowe stawki, czy wylądujesz w wyścigu na najniższą cenę.
Stabilność dochodu kontra elastyczność i wpływ na stawki
Na etacie masz względnie przewidywalne wynagrodzenie – miesiąc w miesiąc podobna kwota, niezależnie od tego, ilu klientów ma firma. Freelancer IT przyjmuje na siebie pełną zmienność rynku. W jednym miesiącu możesz zamknąć duży projekt, w kolejnym mieć tylko drobne poprawki. Dlatego wejście w ten model bez żadnej poduszki finansowej i planu zdobywania zleceń jest prostym przepisem na stres.
W zamian zyskujesz możliwość większego wpływu na stawkę godzinową lub projektową. Na etacie dyskutujesz raz na rok o podwyżce. Jako freelancer możesz co kilka miesięcy aktualizować cennik, testować inny sposób wyceny (godzina, sprint, rezultat), wybierać branże, które po prostu lepiej płacą. Warunkiem jest umiejętność argumentowania wartości, jaką wnosisz. Bez tego presja dumpingowych stawek szybko wciska się w każdą rozmowę.
Z perspektywy pozyskiwania pierwszych zleceń oznacza to jedno: nie wystarczy tylko „chcieć taniej”, bo „dopiero zaczynam”. Trzeba umieć wyjaśnić, co klient dostaje w zamian za konkretny budżet, a nie ścigać się na to, kto zrobi szybciej i taniej. W przeciwnym razie będziesz przyciągać głównie tych, którzy i tak szukają najniższej możliwej ceny – a tacy rzadko wracają i polecają.
Kto szuka kogo: rekruter vs klient
Na etacie proces wygląda stosunkowo prosto: rekruter widzi twoje CV, profil na LinkedIn, portfolio i to on wychodzi z inicjatywą. Ty odpowiadasz, przechodzisz rozmowy, coś negocjujesz. Jesteś reaktywny. Jako freelancer IT musisz stać się stroną aktywną. To ty inicjujesz kontakt, wysyłasz przemyślane wiadomości, zgłaszasz się do ogłoszeń, odzywasz się do swojej sieci kontaktów.
Ta zmiana mentalna jest często trudniejsza niż sama formalna zmiana formy zatrudnienia. Wielu programistów ma silnie rozwinięte umiejętności techniczne, ale unika sytuacji, w których trzeba „wyjść do ludzi”. Stąd biorą się desperackie zachowania: masowe kopiuj-wklej ofert na portalach freelancowych, wysyłka tych samych wiadomości do 200 firm, pomijanie personalizacji. To wygląda jak spam i w większości przypadków ląduje w koszu.
Efektywne zdobywanie pierwszych zleceń wymaga zupełnie innego podejścia: mniejsza liczba kontaktów, za to lepiej dobranych i mocno dopasowanych komunikatów. Lepszy jest jeden klient, z którym przeprowadzisz sensowną rozmowę i przedstawisz klarowną propozycję, niż dwudziestu, którym wyślesz tę samą wiadomość „Dzień dobry, mogę zrobić wszystko w JavaScript za 20 zł/h”.
Kiedy freelans ma sens, a kiedy lepiej zostać na etacie
Freelans IT nie jest złotym rozwiązaniem dla wszystkich. Dobrze odnajdują się w nim osoby, które:
nie boją się niepewności i są gotowe wziąć odpowiedzialność za swoją sprzedaż,
lubią różnorodność projektów zamiast jednego produktu rozwijanego latami,
mają choć minimalne zacięcie do kontaktu z klientem, tłumaczenia i upraszczania,
potrafią samodzielnie organizować sobie pracę i pilnować terminów,
myślą w kategoriach „problem biznesowy → rozwiązanie”, a nie tylko „ładny kod”.
Z kolei dużo gorzej znoszą ten model osoby, które:
potrzebują bardzo stabilnej, przewidywalnej wypłaty i z góry ustalonej ścieżki,
nie chcą mieć nic wspólnego ze sprzedażą, rozmowami o budżecie, rozliczeniami,
łatwo się stresują, gdy przez kilka tygodni nie widać nowego projektu na horyzoncie,
liczą na to, że „klienci sami się znajdą”, tak jak odzywają się rekruterzy na LinkedIn.
Przed pierwszą próbą zdobywania zleceń jako freelancer IT dobrze jest nazwać rzeczy po imieniu: czy naprawdę chcę przyjąć tę nową rolę, czy bardziej pociąga mnie mit „wolności” niż faktyczne obowiązki związane z własnym mikro-biznesem? Szczera odpowiedź pozwala uniknąć wchodzenia w dumping cenowy tylko po to, by jakoś się utrzymać w niewygodnym dla siebie modelu.
Punkt startu – co musisz mieć zanim zaczniesz szukać zleceń
Twarde minimum techniczne – junior z projektami vs „uczeń z tutoriali”
Zdobywanie pierwszych płatnych zleceń w IT bez zaniżania stawek zaczyna się dużo wcześniej niż przy pierwszej wysłanej ofercie. Kluczowe jest realne minimum techniczne. Różnica między osobą, która w kółko przerabia kursy wideo, a juniorem z dwoma–trzema skończonymi projektami, jest z punktu widzenia klienta ogromna.
Osoba „z tutoriali” często ma rozproszone umiejętności: zna fragmenty technologii, ale nie dowiozła żadnego kompletnego rozwiązania. Klient nie potrzebuje kogoś, kto „umie Reacta” – potrzebuje kogoś, kto potrafi zbudować działającą stronę, prosty panel, integrację z płatnościami czy automatyzację w firmie. Twój poziom nie musi być seniorski. Musi być wystarczający, by dowieźć konkretny, ograniczony zakres prac.
Jako junior-freelancer IT, który chce uczciwie wyceniać swoją pracę, dobrze mieć:
2–3 projekty od A do Z (nawet małe, ale skończone: hostowane, dostępne, opisane),
choćby minimalne doświadczenie z realnym użytkownikiem (znajomy, mały lokalny klient),
umiejętność debugowania i samodzielnego szukania rozwiązań,
świadomość swoich ograniczeń i gotowość powiedzenia „tego nie robiłem, ale mogę zaproponować alternatywę”.
Znacznie łatwiej negocjuje się rozsądne stawki, pokazując konkret: „tu jest panel rezerwacji, który zrobiłem dla salonu fryzjerskiego”, niż opowiadając o tym, że „uczestniczyłem w kilku kursach JavaScript”. Klient płaci za namacalny efekt, nie za obejrzane nagrania.
Niezbędna infrastruktura: firma, faktury, porządek w projektach
Nawet najlepsze portfolio freelancera programisty nie pomoże, jeśli formalności będą zniechęcać klienta. Nie potrzebujesz od razu rozbudowanej spółki, ale musisz wiedzieć, jak wystawić fakturę, jak rozliczyć podatek, jak podpisać prostą umowę. Dla większości początkujących sensownym startem jest jednoosobowa działalność gospodarcza lub współpraca przez platformy rozliczeniowe (w niektórych modelach B2B).
Oprócz formy prawnej przydaje się prosty system ogarniania pracy:
narzędzie do śledzenia zadań (np. Trello, Jira w wersji darmowej, Notion),
prosty arkusz lub aplikacja do śledzenia przychodów i kosztów,
szablony dokumentów: podstawowa umowa, akceptacja zlecenia, rachunek lub faktura.
Klienci, szczególnie biznesowi, inaczej patrzą na kogoś, kto ma uporządkowane zaplecze. Gdy mówisz: „Pracujemy na podstawie tej prostej umowy, rozliczamy się co dwa tygodnie, wystawiam fakturę VAT/bez VAT, płatność 7 dni”, brzmisz jak profesjonalista, nawet jeśli dopiero zdobywasz pierwsze zlecenia.
Bez tego wchodzi chaos: ustalenia na Messengerze, brak jasnych terminów, nieokreślone zakresy prac. W takich warunkach trudniej obronić sensowną stawkę, a znacznie łatwiej wpaść w pułapkę „jeszcze tylko jedna mała zmiana za darmo”.
Gotowość czasowa i mentalna – dorabianie vs życie z freelansu
Freelans IT można traktować na dwa sposoby:
dorabianie do etatu – pojedyncze zlecenia po godzinach, bez dużej presji,
główne źródło utrzymania – pełne zaangażowanie, regularne projekty, rozwój marki.
Oba podejścia są poprawne, ale wymagają innych decyzji. Jeśli chcesz jedynie dorobić, możesz spokojniej dobierać projekty, a nawet czasem zejść nieco ze stawki w zamian za ciekawe doświadczenie – byle świadomie, a nie z automatu. Gdy plan jest taki, by żyć wyłącznie z freelansu, dumping cenowy szybko zemści się na zdrowiu i motywacji.
Gotowość mentalna oznacza też zdolność do mówienia „nie”: odmawiania toksycznym klientom, negocjowania realnych terminów, nieprzyjmowania zleceń, które są skazane na porażkę z powodu budżetu i zakresu. Początkujący freelancerzy często biorą wszystko, co się rusza – w efekcie pracują dużo, zarabiają mało i spalają się jeszcze przed zbudowaniem solidnej bazy klientów.
Komunikacja z nietechnicznym klientem – kompetencja krytyczna
Na starcie kariery freelancera IT umiejętność tłumaczenia z języka technicznego na biznesowy jest bardziej decydująca niż znajomość kolejnego frameworka. Klient, który prowadzi salon, sklep internetowy czy małą firmę usługową, nie chce słuchać o bibliotekach i patternach. Chce usłyszeć:
jak rozwiązanie wpłynie na jego sprzedaż,
jak odciąży go lub jego zespół,
jak zmniejszy ryzyko błędów czy chaosu,
ile to będzie kosztować i w jakim czasie powstanie.
Początkujący freelancerzy często wchodzą w techniczny monolog, budując dystans zamiast zaufania. Skuteczniejszy jest prosty schemat: problem → rozwiązanie → efekt. Zamiast „zbuduję SPA w React z Reduxem”, lepiej: „zrobimy panel rezerwacji, w którym klienci sami wybiorą termin, a Pan dostanie powiadomienie SMS. Teraz część telefonów przepada, bo nikt nie odbiera po 18:00. Po wdrożeniu taka sytuacja się nie zdarzy”.
Ta kompetencja przydaje się w każdym kanale pozyskiwania zleceń – od pierwszej rozmowy, przez ofertę, aż po negocjowanie stawek. Pomaga też unikać potrzeby ostrego zaniżania cen. Klient, który rozumie, jaką konkretną wartość otrzyma, jest mniej skłonny licytować się o każde 10 zł na godzinie.
Przykład: bootcamp + open-source vs same kursy wideo
Dwie osoby w podobnej sytuacji szukają pierwszych zleceń jako freelancer IT:
Pierwsza ukończyła bootcamp, zrobiła projekt dla małego NGO i dołożyła pull request do niewielkiego projektu open-source.
Druga ma za sobą kilkanaście kursów wideo, kilka projektów „zrobionych razem z prowadzącym”, ale niczego nie opublikowała ani nie wykorzystała w realnym kontekście.
Z punktu widzenia klienta biznesowego pierwsza osoba wygrywa natychmiast. Może pokazać: „Tu jest strona organizacji X, zrobiłem ją w tym i tym narzędziu, z takim formularzem darowizn. Wcześniej korzystali z darmowego szablonu, darczyńcy gubili się w procesie”. Druga osoba ogranicza się do zdania: „Znam Reacta i Node, robiłem projekty w kursach”. To duża różnica w wiarygodności, a od niej zależy Twoja możliwość negocjowania stawek zamiast schodzenia do poziomu „byleby ktoś coś mi zapłacił”.
Źródło: Pexels | Autor: Lukas Blazek
Portfolio freelancera IT, które sprzedaje bez agresywnego spamowania
GitHub to nie wszystko – perspektywa klienta biznesowego
Dla wielu programistów portfolio = GitHub pełen repozytoriów. Z perspektywy klienta spoza IT GitHub wygląda jak zbiór losowych plików z dziwnymi nazwami. Klient biznesowy nie ocenia jakości Twoich commitów. Interesuje go, czy jesteś w stanie rozwiązać jego konkretny problem.
Dlatego skuteczne portfolio freelancera IT powinno mówić przede wszystkim o:
Jak opisywać projekty, żeby klient „zobaczył” efekt
Sam link do repozytorium lub działającej aplikacji to połowa roboty. Osoba po drugiej stronie rzadko ma czas i kompetencje, żeby klikać po wszystkich zakładkach i domyślać się, co tu jest wyjątkowego. Projekt trzeba sprzedać krótką historią.
Dobry opis projektu dla klienta nietechnicznego zawiera zwykle cztery elementy:
kontekst – dla kogo to powstało i w jakiej sytuacji,
problem – co konkretnie było bolączką użytkownika lub firmy,
rozwiązanie – co zostało zrobione, w języku zrozumiałym biznesowo,
Krótki przykład opisu w wersji „technicznej” kontra „biznesowej”:
Wersja techniczna: „Aplikacja w React + Node, autoryzacja JWT, integracja z API Google Calendar.”
Wersja biznesowa: „System rezerwacji wizyt dla jednoosobowego gabinetu fizjoterapii. Klienci mogą samodzielnie umawiać wizyty online, a terminy synchronizują się z kalendarzem Google właścicielki. Wcześniej umawianie odbywało się tylko telefonicznie – część telefonów przepadała, a terminy nakładały się na siebie.”
Ta sama praca, ale druga wersja pokazuje, po co to w ogóle powstało. Dla klienta biznesowego to sygnał: „Ten freelancer rozumie problemy firm, nie tylko technologie”.
Strona-portfolio vs same profile w serwisach – dwa modele obecności
Początkujący freelancer IT zwykle stoi między dwoma opcjami:
minimalistycznie: GitHub + LinkedIn + profil na jednym portalu ze zleceniami,
bardziej samodzielnie: prosta strona-portfolio na własnej domenie + profile uzupełniające.
Oba podejścia działają, ale niosą inne konsekwencje.
Same profile w serwisach są szybsze na start. Nie trzeba inwestować wielu godzin w stronę, wystarczy porządnie uzupełnić opisy, projekty, nagłówki. Minusy:
jesteś jednym z wielu podobnych profili – trudniej się wyróżnić bez obniżania stawki,
zależysz od algorytmów i regulaminów platformy,
czasem trudno zbudować „wizerunek eksperta”, gdy obok jest 50 ofert „zrobię taniej”.
Własna strona-portfolio wymaga więcej pracy na wejściu, ale daje inny poziom kontroli:
możesz pokazać projekty w takim układzie, jaki Ci pasuje (case studies, branże, typy rozwiązań),
masz jedno miejsce, do którego odsyłasz z ogłoszeń, LinkedIna czy maili,
łatwiej zbudować wrażenie, że prowadzisz usługę, a nie „łapiesz cokolwiek”.
Na start często sprawdza się wersja hybrydowa: prosta strona na jednym z gotowych szablonów (np. jeden landing z 3–4 projektami i kontaktem) + dobrze dopracowany profil LinkedIn. Portale ze zleceniami są wtedy dodatkiem, a nie głównym miejscem, od którego zależy Twój los.
Case study zamiast „galerii screenów”
Portfolio wielu początkujących wygląda jak album z obrazkami: screen aplikacji, logo technologii i lakoniczny opis. Taki format nie pomaga obronić sensownej stawki, bo nie pokazuje procesu ani myślenia. Zestawienie dwóch podejść jest dość proste:
Galeria screenów – klient widzi, że coś istnieje, ale nie wie, ile wysiłku wymagało dojście do tego efektu.
Mini case study – klient rozumie, z czym się mierzyłeś, jakie decyzje podjąłeś i jak to przełożyło się na efekt.
Case study nie musi być długie. Wystarczą 3–4 akapity:
Sytuacja wyjściowa: „Mały sklep online z rękodziełem, właścicielka sama obsługiwała zamówienia przez e‑mail.”
Problem: „Część zamówień ginęła w skrzynce, klienci czekali długo na odpowiedź, brakowało systemu do śledzenia statusu.”
Rozwiązanie: „Zbudowałem prosty panel zamówień z formularzem zakupowym, automatycznymi powiadomieniami mailowymi i widokiem statusów dla właścicielki.”
Efekt: „Obsługa zamówień przeszła z maila do systemu, właścicielka ma podgląd wszystkich transakcji, a klienci dostają potwierdzenia natychmiast po złożeniu zamówienia.”
Taki opis pokazuje, że potrafisz przełożyć potrzeby biznesowe na rozwiązania techniczne. To dużo ważniejsze przy ustalaniu stawek niż sam zestaw użytych bibliotek.
Jedna specjalizacja czy wszystko po trochu?
Przy budowaniu portfolio pojawia się dylemat: pokazać się jako „człowiek od wszystkiego” czy raczej zawęzić opis do jednego–dwóch typów zleceń. Każde podejście ma swoje konsekwencje dla sposobu pozyskiwania klientów.
Freelancer „od wszystkiego” może liczyć na większą liczbę potencjalnych ogłoszeń, ale zwykle ma słabszy argument przy negocjowaniu stawki. Konkurencją stają się wtedy osoby gotowe zrobić „to samo” za mniej, bo z zewnątrz oferty wyglądają podobnie.
Freelancer wyspecjalizowany (np. „proste sklepy dla małych marek”, „automatyzacje w Google Workspace”, „landing page + integracje marketingowe”) od razu wysyła inny sygnał: „mam doświadczenie w rozwiązywaniu takich problemów jak Twój”. Efekt bywa taki, że:
przychodzi mniej zapytań ogółem,
ale większy odsetek jest konkretny i skłonny do rozmowy o wartości, nie tylko o cenie.
Na samym początku rozsądne jest lekkie zawężenie, a nie radykalna specjalizacja. Zamiast „zrobię wszystko w JavaScript”, można komunikować: „tworzę małe aplikacje i panele administracyjne, które automatyzują ręczne zadania w małych firmach”. Nadal zrobisz różne projekty, ale klient nie będzie Cię mylił z „randomem z grupy na Facebooku”.
Jak pokazywać „małe” projekty, żeby nie wyglądały na niepoważne
Początki to często zlecenia typu: prosta strona, formularz, integracja płatności, poprawki po innym wykonawcy. Z zewnątrz wydaje się to mało atrakcyjne w portfolio. Kluczowe jest to, jak je opiszesz.
Zamiast wpisu „strona wizytówka dla salonu X”, lepiej napisać:
co dokładnie było celem (np. „klienci mieli znaleźć numer telefonu i listę usług w 30 sekund na telefonie”),
z jakimi ograniczeniami pracowałeś (mały budżet, krótki czas, istnienie starej wersji strony),
jak rozwiązałeś problem (np. jedna prosta strona zamiast rozbudowego serwisu).
Nawet prosta integracja systemu rezerwacji może wyglądać inaczej w portfolio:
wersja 1: „Integracja kalendarza rezerwacji z istniejącą stroną WordPress.”
wersja 2: „Dołączyłem system rezerwacji do istniejącej strony gabinetu kosmetycznego. Wcześniej umawianie było wyłącznie telefoniczne, teraz część klientek wybiera termin online – właścicielka ma mniej przerw w pracy na odbieranie telefonu.”
Druga forma od razu pokazuje, że rozumiesz codzienność klienta, a nie tylko instalację wtyczek.
Gdzie szukać pierwszych zleceń – przegląd kanałów z porównaniem
Portale ze zleceniami: szybki start vs konkurencja cenowa
Klasyczne portale (polskie i zagraniczne) są naturalnym pierwszym wyborem. Dają szybki dostęp do wielu ogłoszeń, ale mechanika gry sprzyja obniżaniu stawek. Warto podejść do nich jak do jednego z kanałów, a nie jedynego.
Plusy portali:
stały napływ nowych ogłoszeń,
czytelne kryteria: budżet, zakres, termin,
często wbudowany system rozliczeń i opinii.
Minusy:
dużo szablonowych ofert „kopiuj-wklej” od innych wykonawców,
klienci często porównują głównie cenę i ilość „gwiazdek”,
łatwo wejść w licytację w dół („kto zrobi najtaniej”).
Na takich serwisach lepiej zgłaszać się do mniejszej liczby, ale lepiej dopasowanych zleceń, niż strzelać setkami odpowiedzi. Dobrze też od początku jasno komunikować zakres, który jest w cenie, i dolne granice wynagrodzenia. Dzięki temu przyciągasz mniej zapytań „za grosze”, a więcej rozmów z klientami, którzy szukają sensownego kompromisu jakość–cena.
LinkedIn i sieci zawodowe – dłuższa gra, wyższe stawki
Portale z ogłoszeniami przypominają targ: dużo hałasu, wielu sprzedawców, klienci chodzą i porównują. LinkedIn i inne sieci zawodowe są bliżej klubu biznesowego: mniej przypadkowych osób, więcej relacji i poleceń.
Plusy LinkedIna i podobnych kanałów:
łatwiej dotrzeć do decydentów (właścicieli firm, managerów),
silniejsza rola rekomendacji i historii współpracy,
większa akceptacja wyższych stawek przy konkretnym uzasadnieniu wartości.
Minusy:
trzeba zbudować choć minimalną obecność (profil, kilka sensownych wpisów, aktywność),
efekty przychodzą wolniej niż z portali ogłoszeniowych,
łatwo przesadzić z nachalnymi wiadomościami prywatnymi i wpaść w kategorię spamu.
Na start lepiej działa aktywność wokół konkretnych tematów niż masowe wysyłanie zaproszeń. Kilka pomysłów:
komentowanie postów właścicieli małych firm, którzy opisują swoje problemy z technologią,
krótkie wpisy pokazujące fragmenty Twoich projektów (np. „przed/po” procesu rezerwacji, automatyzacji raportów),
dołączanie do dyskusji w grupach branżowych (e‑commerce, szkolenia online, usługi lokalne).
Z czasem pojawiają się zapytania „z polecenia”, mimo że oficjalnie „nie szukałeś”. Takie leady są zwykle mniej wrażliwe na cenę, bo ktoś już za Ciebie zbudował część zaufania.
Znajomi, polecenia i lokalny rynek – niedoceniony kanał na start
Wielu freelancerów zaczyna od internetu, a pomija najprostszy obszar: ludzi, których już znają. Nie chodzi o namawianie rodziny na „kupno strony”, tylko o spokojne sprawdzenie, gdzie technologia mogłaby realnie pomóc.
Różnica między dwoma podejściami jest wyraźna:
nachalne: „Zrobię Ci stronę, bo jestem początkującym programistą, potrzebuję zleceń”,
partnerskie: „Widzę, że umawiasz klientów głównie przez telefon. Mogę zaproponować prosty system rezerwacji online, który odciąży Cię z części rozmów – chcesz, żebym pokazał Ci, jak mogłoby to wyglądać?”.
Małe lokalne firmy – fryzjerzy, fizjoterapeuci, konsultanci, trenerzy, sklepy z wysyłką – często nie chcą wielkich i drogich systemów. Potrzebują prostego usprawnienia: kalendarza, formularza, podpięcia płatności, automatycznych potwierdzeń. To dobry obszar do pierwszych zleceń, które można później opisać w portfolio jako konkretne case studies.
Społeczności branżowe i grupy tematyczne – gdzie jest granica między aktywnością a spamem
Grupy na Facebooku, Slacki, Discordy, fora – to miejsca, w których klienci często nie piszą wprost „szukam programisty”, ale opisują swoje kłopoty. Różnica między skutecznym a toksycznym działaniem jest jednak cienka.
Dwa style zachowania w takiej grupie:
„Łowca zleceń”: pod każdym postem o problemie technicznym komentarz „napisz priv”, bez żadnej merytoryki. Szybko trafia na czarną listę społeczności.
„Pomagający ekspert”: podaje konkretne wskazówki, czasem link do dokumentacji, czasem propozycję prostego obejścia. Dopiero gdy rozmowa naturalnie dojdzie do „kto może to wdrożyć”, proponuje swoje usługi.
Druga strategia jest wolniejsza, ale prowadzi do bardziej świadomych klientów, którzy już doświadczyli Twojej pomocy. W efekcie częściej pytają „ile to będzie kosztować?”, a rzadziej „czy zrobi Pan to za 200 zł?”.
Agencje i software house’y jako źródło podwykonawstwa
Dla wielu początkujących freelancerów pierwsze stabilniejsze zlecenia przychodzą nie od klientów końcowych, ale od agencji interaktywnych, marketingowych i software house’ów. To inny rodzaj współpracy niż „zrobię stronę dla lokalnego salonu”, z innymi plusami i pułapkami.
Typowo masz do wyboru dwa modele:
krótkie „strzały” – pojedyncze podzadania: poprawki na froncie, integracja płatności, wdrożenie projektu graficznego,
dłuższe „sloty” – kilka tygodni lub miesięcy pracy nad projektem klienta agencji, prawie jak mini‑etat.
Krótki podwykonawca ma więcej różnorodności, ale musi stale szukać następnych zadań. Dłuższa współpraca jest przewidywalna, lecz szybciej zbliża się do modelu „etat przez B2B” – z mniejszą swobodą i zwykle sztywniejszą stawką.
Plusy wejścia w podwykonawstwo:
nie musisz prowadzić pełnej sprzedaży – agencja już pozyskała klienta,
jasna specyfikacja (częściej są makiety, wymagania, procedury),
szansa, że po jednym udanym projekcie dostaniesz kolejny, bez szukania na nowo.
Minusy:
niższa stawka godzinowa/projektowa niż przy kliencie bezpośrednim (agencja musi zarobić swoją marżę),
mniejsza kontrola nad zakresem i terminami – dochodzi pośrednik,
często brak możliwości pokazania projektu w portfolio pod własnym brandem lub z własnym logo.
Żeby nie wpaść w pułapkę „ukrytego etatu za pół darmo”, przy pierwszych rozmowach dobrze dopytać:
ile godzin tygodniowo realnie przewidują,
czy rozliczenie jest za zadania, sprinty, czy za „czas dostępności”,
czy możesz pokazać fragmenty pracy w portfolio (choćby anonimowo),
kto odpowiada przed klientem za zakres i zmiany (Ty vs project manager agencji).
Na początek współpraca z jedną–dwiema agencjami daje bazową stabilność, a resztę czasu można przeznaczyć na budowanie własnych kanałów pozyskiwania klientów, gdzie to Ty decydujesz o stawkach i zasadach.
Jak pisać oferty i odpowiedzi na ogłoszenia, żeby nie brzmiały jak spam
Dlaczego większość ofert wygląda identycznie
Na portalach z ogłoszeniami i w skrzynkach mailowych klientów króluje jeden styl: długi akapit o „pasji do programowania”, lista technologii i zdanie „zapraszam do kontaktu”. W efekcie 10 wykonawców brzmi jak jeden człowiek, a klient zaczyna patrzeć wyłącznie na cenę i ilość opinii.
Spamowa oferta ma kilka powtarzalnych cech:
nie odnosi się w ogóle do treści ogłoszenia,
jest w 100% o wykonawcy („ja, ja, ja”),
jest wysyłana w identycznej formie do dziesiątek ogłoszeń.
Anty‑spamowa oferta robi odwrotnie: zaczyna od klienta, nie od Ciebie, pokazuje, że rozumiesz jego sytuację, a dopiero potem przechodzi do tego, jak możesz pomóc.
Struktura odpowiedzi na ogłoszenie, która nie wygląda na masówkę
Dobrze działa prosty szkielet, który można szybko dopasować do konkretnego ogłoszenia. Nie chodzi o literackie popisy, tylko o przejrzystą logiczną strukturę.
Krótki odnośnik do ogłoszenia – 1–2 zdania pokazujące, że wiesz, o czym mowa. „Z ogłoszenia widzę, że zależy Panu na prostym sklepie z integracją płatności i możliwością samodzielnej edycji produktów.”
Twoje doświadczenie, ale w kontekście ich problemu – nie lista technologii, tylko podobne realizacje. „W ostatnich miesiącach robiłem dwa podobne sklepy dla małych marek – właściciele sami dodają produkty, a płatności są obsługiwane przez Przelewy24 i Blika.”
Propozycja podejścia – jak widzisz realizację, krokowo, bez wchodzenia w zbędne szczegóły techniczne. „Proponuję podzielić pracę na etapy: prosty projekt układu, wdrożenie sklepu, konfiguracja płatności i krótkie przeszkolenie z obsługi panelu.”
Zakres + widełki budżetowe / szacunek czasowy – tak, by klient wiedział, czy w ogóle jest sens rozmawiać dalej. „Przy takim zakresie całość zwykle zamyka się w przedziale X–Y zł i 2–3 tygodniach pracy, w zależności od liczby produktów i materiałów.”
Proste call‑to‑action – jedno konkretne następne działanie, bez nacisku. „Jeśli budżet i ramy czasowe są zbliżone do Pana oczekiwań, mogę dziś wieczorem podesłać krótką listę pytań, żeby doprecyzować zakres.”
Taki schemat można odchudzić (np. na portale z limitem znaków) albo rozwinąć (w mailu po rozmowie telefonicznej), ale rdzeń zostaje ten sam: konkret, kontekst, kolejny krok.
Jak używać szablonów, żeby nie skończyło się spamem
Szablony same w sobie nie są problemem. Problemem jest lenistwo w ich dopasowywaniu. Dwie skrajności wyglądają tak:
Zero szablonów – każdą ofertę piszesz od zera. Mało spamu, ale ogromny czas i ryzyko chaosu w komunikacji.
Szablon 1:1 – zmieniasz tylko imię klienta i tytuł projektu. Szybko, ale lądujesz w koszu razem z resztą „masówek”.
Zdrowsze podejście to pół‑szablon:
stałe fragmenty: krótkie przedstawienie, 2–3 przykłady realizacji w danym typie projektu, sposób pracy,
ruchome fragmenty: wstęp, propozycja podejścia i zakres – pisane pod dane ogłoszenie.
Dobrą praktyką jest zostawienie w szablonie pustych „haków”, które wymuszają personalizację, np.:
„Wspomina Pan/Pani o [główny problem z ogłoszenia] – w podobnej sytuacji rozwiązywałem to tak…”
„Istotna jest dla Pana/Pani [kluczowy warunek: np. termin, prostota obsługi] – dlatego proponuję…”
Jeśli po wklejeniu oferty mógłbyś ją wysłać w niemal niezmienionej formie do dziesięciu innych ogłoszeń, to sygnał ostrzegawczy. Taka wiadomość najczęściej wygląda jak spam, nawet jeśli nie miałeś takiej intencji.
Język oferty: technicznie vs biznesowo
W IT łatwo przesadzić w dwie strony:
zbyt technicznie – klient dostaje ścianę pojęć, których nie rozumie („SSR, CSR, headless CMS, event‑driven architecture”),
zbyt ogólnie – oferta brzmi, jakby pisał ją każdy („stworzę nowoczesną, szybką stronę dopasowaną do Twoich potrzeb”).
Różnica między sensownym poziomem techniki a żargonem jest prosta: czy człowiek nietechniczny na tej podstawie jest w stanie podjąć decyzję.
Przykład porównawczy:
wersja techniczna: „Zastosuję Reacta z SSR, podłączę się do headless CMS i przygotuję CI/CD.”
wersja mieszana (zrozumiała dla klienta): „Użyję sprawdzonego frameworka, dzięki czemu strona będzie szybko działać i łatwo ją rozbudujesz w przyszłości. Treści będzie Pan/Pani mógł/mogła zmieniać samodzielnie w prostym panelu, bez wchodzenia w kod.”
Technikę warto zostawić głównie do rozmowy z technicznymi decydentami (CTO, senior developer), a przy właścicielu małej firmy postawić na skutki: szybkość, bezpieczeństwo, wygoda obsługi, mniej błędów ręcznych, mniejsza ilość telefonów od klientów.
Jak mówić o stawkach, żeby nie zejść do poziomu dumpingu
Rozmowa o pieniądzach jest momentem, w którym wielu początkujących automatycznie obniża swoje oczekiwania „żeby tylko dostać zlecenie”. Zaczyna się niewinnie („na start mogę zrobić taniej”), a kończy na serii projektów, których nie da się finansowo obronić.
Można postąpić na co najmniej trzy sposoby:
„Powiem, co chce klient” – pytasz: „Jaki budżet Pan/Pani przewiduje?” i akceptujesz pierwszą kwotę. Szybko dostajesz zlecenie, ale równie szybko lądujesz na stawce, z której trudno wyjść.
„Zafiksuję się na stawce godzinowej” – mówisz „X zł/h” bez kontekstu zakresu i efektów. Lepsze niż nic, ale klient dalej porównuje tylko liczby.
„Zakres + widełki” – łączysz orientacyjny zakres prac z przedziałem cenowym i prostym uzasadnieniem.
Przykładowa, spokojna odpowiedź:
„Przy takim zakresie (prosta strona informacyjna, formularz kontaktowy, podpięcie domeny i hostingu) zwykle pracuję w przedziale 2500–3500 zł brutto. Dolna granica zakłada gotowe teksty i zdjęcia, górna – jeśli mamy razem dopracowywać treści i dodatkowe sekcje. Po krótkiej rozmowie telefonicznej mogę podać konkretną wycenę.”
W ten sposób:
nie zbijasz od razu ceny,
pokazujesz, że stawka wynika z zakresu, a nie z „widzimisię”,
zostawiasz sobie przestrzeń do małej negocjacji, nie do ucięcia ceny o połowę.
Jeśli słyszysz: „Ktoś inny zrobi to za połowę tej kwoty”, masz dwie drogi: zejść poniżej swojego minimum i utwierdzić rynek, że tak się da – albo spokojnie odmówić, tłumacząc, że przy niższym budżecie musiałbyś obciąć konkretny element (np. testy, szkolenie, wsparcie po wdrożeniu). Druga opcja nie daje szybkiego zlecenia, ale chroni Twój poziom stawek na kolejne miesiące.
Konkretny przykład oferty na proste zlecenie
Dla porównania dwa style odpowiedzi na ten sam typ ogłoszenia: „Szukam kogoś do zrobienia prostej strony wizytówki dla gabinetu fizjoterapii”.
Wersja spamowa:
„Dzień dobry, jestem początkującym programistą, zrobię stronę tanio i szybko. Znam HTML, CSS, JavaScript, WordPress, PHP, MySQL. Zapraszam do kontaktu.”
Brzmi znajomo? Brak odniesienia do potrzeb klienta, brak zakresu, brak czegokolwiek, co odróżnia tę osobę od dziesiątek innych.
Wersja anty‑spamowa:
„Dzień dobry,
z ogłoszenia rozumiem, że potrzebuje Pan/Pani prostej strony wizytówki dla gabinetu – tak, aby pacjenci mogli szybko znaleźć informacje o usługach, cennik i dane kontaktowe (telefon, adres, mapkę).
W ostatnim czasie robiłem podobną stronę dla małego gabinetu masażu. Najważniejsze było to, żeby na telefonie wszystko zmieściło się na jednej dłuższej stronie, a pacjenci nie błądzili po menu. Właścicielka sama podmienia teraz godziny przyjęć w prostym panelu.
Proponuję podejść do Pana/Pani projektu w 3 krokach: krótka rozmowa o tym, jakie informacje są kluczowe dla pacjentów, przygotowanie prostego układu strony (do akceptacji) i wdrożenie na wybranej domenie, wraz z krótką instrukcją obsługi.
Przy takim zakresie moja praca zwykle mieści się w przedziale X–Y zł, a czas realizacji to ok. 7–10 dni roboczych od momentu otrzymania materiałów (treści, logo, zdjęć). Jeśli ten rząd wielkości jest dla Pana/Pani akceptowalny, mogę dziś wieczorem przesłać 5 krótkich pytań, żeby doprecyzować szczegóły.
Pozdrawiam, [Imię i nazwisko]”
To wciąż krótka wiadomość, ale klient widzi, że:
ktoś przeczytał ogłoszenie,
rozumie specyfikę jego branży,
ma plan działania i konkretny przedział cenowy.
W takim układzie nawet jeśli wybierze kogoś innego, nie kojarzy Cię z „kopiuj‑wklej”, lecz z profesjonalnym podejściem – a to często wraca w przyszłych poleceniach.
Najczęściej zadawane pytania (FAQ)
Jak znaleźć pierwsze zlecenia jako freelancer IT bez wysyłania spamu?
Najprostsze porównanie: zamiast rozsyłać jedną, ogólną wiadomość do 200 firm, lepiej wysłać 10 mocno spersonalizowanych. Zanim napiszesz do potencjalnego klienta, sprawdź, czym się zajmuje, jakie ma produkty, z jakich technologii korzysta i gdzie realnie możesz coś usprawnić. W wiadomości odnieś się konkretnie do jego sytuacji, a nie tylko do swojego CV.
Dobrze działa połączenie trzech kanałów: ogłoszenia na portalach (z przemyślanymi odpowiedziami), kontakt do firm z twojej niszy (np. małe e‑commerce, salony usługowe) oraz sięganie po własną sieć kontaktów – dawni współpracownicy, znajomi z branży, lokalni przedsiębiorcy. Zamiast „robię wszystko”, zaproponuj 1–2 typowe problemy, które możesz rozwiązać (np. prosty panel rezerwacji, automatyzacja faktur, integracja płatności).
Jak ustalić pierwszą stawkę jako freelancer IT, żeby nie robić dumpingu?
Najpierw określ swój realny poziom: „uczeń z tutoriali” kontra junior z 2–3 skończonymi projektami. Ten drugi może już negocjować sensowne stawki, bo pokazuje efekty, nie tylko znajomość frameworka z kursu. Porównaj swoje kompetencje do rynkowych widełek dla juniora na etacie i weź pod uwagę, że jako freelancer ponosisz dodatkowe koszty (podatki, ZUS, czas sprzedaży, brak płatnych urlopów).
Zamiast schodzić z ceny „bo dopiero zaczynasz”, lepiej ograniczyć zakres prac: mniejszy projekt za uczciwą stawkę niż ogromny system za grosze. Dobrze działa rozbicie wyceny na pakiety lub zakresy (MVP, wersja rozbudowana) oraz jasne pokazanie, co klient zyskuje biznesowo za konkretny budżet, a nie tylko ile kodu powstanie.
Czy można zdobyć pierwsze zlecenia, jeśli mam tylko kursy online, bez komercyjnego doświadczenia?
Z samymi kursami jest trudno, bo klient płaci za dowieziony rezultat. Różnica między osobą „z tutoriali” a juniorem z projektami jest duża: ten drugi ma coś, co można kliknąć, zobaczyć, przetestować. Jeśli jesteś na etapie kursów, dobrym krokiem pośrednim jest zbudowanie 2–3 małych, ale skończonych projektów – najlepiej hostowanych, opisanych, z choć jednym realnym użytkownikiem.
Lepsza jest współpraca z lokalnym salonem, małą kawiarnią czy znajomym przedsiębiorcą za niewielki, ale normalnie policzony budżet, niż kolejne „projekty do szuflady”. Dzięki temu w rozmowie możesz powiedzieć: „tu jest panel rezerwacji, który działa w tej firmie”, zamiast: „przerobiłem pięć kursów Reacta”. To często decyduje, czy klient zaakceptuje twoją wycenę.
Freelancer IT czy etat – co lepiej wybrać na start kariery?
Etat daje przewidywalność: stałą pensję, projekty organizowane przez firmę, brak konieczności szukania klientów i pilnowania płatności. Dobrze sprawdza się u osób, które wolą stabilność, jasną ścieżkę awansu i nie chcą zajmować się sprzedażą czy negocjacjami budżetu.
Freelans to większa elastyczność i wpływ na stawkę, ale też pełna odpowiedzialność za przychody i okresy „bez projektu”. Lepiej odnajdują się w nim osoby, które akceptują niepewność, lubią różnorodność projektów i są gotowe rozmawiać z klientami o ich problemach biznesowych, nie tylko o technologii. Na sam start kariery bez żadnej poduszki finansowej i bez projektów w portfolio model etatowy bywa po prostu bezpieczniejszy.
Od czego zacząć formalnie: czy potrzebuję firmy, żeby brać zlecenia w IT?
Są dwa podstawowe podejścia. Pierwsze: zakładasz jednoosobową działalność gospodarczą (lub inną formę B2B) i sam wystawiasz faktury, rozliczasz podatki, podpisujesz umowy. Drugie: korzystasz z pośrednich platform rozliczeniowych, które „wynajmują” ci swoją osobowość prawną – wtedy często nie musisz od razu mieć własnej firmy, ale płacisz za obsługę pośrednika.
Niezależnie od formy ważne jest, by umieć w praktyce: wystawić fakturę, zawrzeć prostą umowę (zakres prac, terminy, płatności, prawa autorskie) oraz mieć porządek w projektach. Nawet najprostszy system typu Trello/Notion + arkusz przychodów i kosztów jest lepszy niż chaos w notatkach i skrzynce mailowej.
Jak uniknąć sytuacji, w której biorę „wszystko jak leci” za byle jakie pieniądze?
Tu przydaje się kilka granic spisanych z góry: minimalna stawka, poniżej której nie schodzisz, typy projektów, których nie bierzesz (np. „naprawa po pięciu innych wykonawcach za 500 zł”) oraz maksymalna liczba równoległych zleceń. Jeśli tego nie określisz, łatwo wpaść w pułapkę brania każdego zlecenia tylko po to, by „coś wpływało na konto”.
Dobrym filtrem jest pytanie: „czy to zlecenie pomaga mi budować portfolio, stawkę lub relację na przyszłość?”. Jeśli odpowiedź brzmi „nie” i przy okazji budżet jest żaden, często rozsądniej odmówić. Zamiast śrubować ilość projektów za grosze, lepiej poświęcić ten czas na szukanie bardziej dopasowanych klientów lub dopracowanie oferty i portfolio.
Jak mentalnie przestawić się z bycia pracownikiem na etacie na freelancera IT?
Na etacie działasz reaktywnie: ktoś przydziela zadania, rekruterzy sami piszą na LinkedIn, przełożony organizuje pracę. We freelansie musisz stać się stroną aktywną – to ty inicjujesz kontakt, proponujesz rozwiązania, przypominasz się w sprawie płatności, negocjujesz zakres. Ta zmiana bywa trudniejsza niż sama rejestracja działalności.
Pomaga myślenie w kategoriach „mikro-biznesu”: nie jesteś tylko programistą, ale jednocześnie sprzedawcą, marketerem i osobą od obsługi klienta. Jeśli perspektywa rozmów o budżecie, szukania zleceń i okresów bez projektów budzi silny sprzeciw, lepiej to zauważyć wcześniej niż później. Wtedy freelans może być dodatkiem obok etatu, a nie od razu pełnym zamiennikiem.
Najważniejsze wnioski
Przejście z etatu na freelans to zmiana modelu pracy: z „robię zadania” na „prowadzę mały biznes”, w którym oprócz programowania dochodzą sprzedaż, marketing, negocjacje i pilnowanie płatności.
Stabilna pensja etatowa zamienia się w zmienny dochód, więc potrzebne są poduszka finansowa i plan pozyskiwania zleceń; w zamian rośnie wpływ na stawki, sposób wyceny i dobór branż.
Pierwsze zlecenia bez dumpingu wymagają umiejętności pokazania wartości dla biznesu klienta, a nie tylko niskiej ceny; ściganie się „kto zrobi taniej” przyciąga jednorazowych, mało lojalnych klientów.
Na etacie to rekruter szuka programisty, we freelansie role się odwracają – to freelancer aktywnie wychodzi do klientów, personalizuje kontakt i stawia na jakość rozmów zamiast masowego spamu.
Freelans sprzyja osobom odpornym na niepewność, samodzielnym i gotowym do rozmów o pieniądzach, a jest męczący dla tych, którzy potrzebują stałej pensji, jasno wytyczonej ścieżki i chcą uniknąć tematu sprzedaży.
Decyzja o wejściu w freelans powinna być świadoma: chodzi o przyjęcie roli właściciela mikro‑biznesu, a nie pogoń za mitem „wolności”, który kończy się zaniżaniem stawek, byle tylko mieć jakiekolwiek zlecenia.
Start na rynku usług IT bez spamu i dumpingu zaczyna się od realnego minimum technicznego i skończonych projektów, a nie od samego przerabiania tutoriali – dopiero wtedy można sensownie rozmawiać o budżecie i efektach.
