Sam, ale nie samotny
Prowadzenie projektów jako jedna osoba brzmi ryzykownie. Dla wielu klientów to pierwsza czerwona flaga, “co jeśli coś mu się stanie”, “co jeśli zniknie”, “kto to ogarnie, jak on zachoruje”. Rozumiem te obawy, sam bym je miał, zanim spróbowałem tego modelu na własnej skórze.
W praktyce solo development to nie jest brak zespołu, to inny sposób organizacji pracy. Zamiast rozpraszać odpowiedzialność między pięć osób, skupiam ją w jednym miejscu. Mniej osób nie oznacza mniej kompetencji. Oznacza mniej tarcia.
Nie pracuję zresztą w próżni, korzystam z narzędzi, agentów AI, czasem podwykonawców do wąskich zadań. Różnica jest taka, że to ja decyduję, kiedy i z kim, a nie sztywna struktura firmy, która musi utrzymać ludzi w ruchu niezależnie od tego, czy akurat są potrzebni.
Mniej warstw komunikacji
W klasycznej agencji droga informacji wygląda mniej więcej tak: klient pisze do account managera, ten przekazuje do project managera, project manager pyta developera, developer odpowiada project managerowi, ten wraca do account managera, a dopiero na końcu klient dostaje odpowiedź. Każda warstwa to szansa na zniekształcenie komunikatu i kolejny dzień opóźnienia.
U mnie to wygląda inaczej: pytanie klienta -> ja -> odpowiedź. Bez tłumaczenia wymagań na “język biznesowy”, a potem z powrotem na techniczny. Bez gubienia kontekstu po drodze. Kiedy klient pisze “chciałbym, żeby to działało trochę inaczej”, ja od razu wiem, o który fragment kodu chodzi, bo sam go pisałem tydzień wcześniej.
To ma też mniej oczywistą zaletę, nie ma pokusy, żeby rozmyć odpowiedzialność za decyzję na kilka osób. Jeśli coś proponuję, to dlatego, że sam za tym stoję, a nie dlatego, że tak ustalił zespół na spotkaniu, w którym nie uczestniczyłem.
Pełna odpowiedzialność
Kiedy kod psuje się na produkcji o drugiej w nocy, nie ma kogo wskazać palcem. Nie ma “to nie mój moduł”, nie ma przerzucania się między frontendem a backendem, nie ma czekania, aż ktoś inny się obudzi i zareaguje. Jest tylko pytanie: naprawiam to teraz, czy jutro rano, i jak szybko.
To brzmi jak ciężar, i czasem nim jest. Ale to samo działa w drugą stronę. Kiedy projekt się udaje, kiedy klient wraca z kolejnym zleceniem albo poleca mnie dalej, to jest w stu procentach efekt mojej pracy. Nie muszę dzielić się uznaniem z zespołem, który akurat miał gorszy tydzień, ani tłumaczyć, że “ta część nie była moja”.
Ta pełna odpowiedzialność zmienia też sposób, w jaki podchodzę do samego kodu. Piszę go tak, jakbym wiedział, że za pół roku to ja będę musiał go czytać i naprawiać, bo tak właśnie jest. Nie ma pokusy, żeby zostawić coś “na później”, licząc, że zajmie się tym kolejna osoba w zespole.
Szybciej, nie wolniej
Największy mit o solo developmencie to przekonanie, że jedna osoba musi pracować wolniej niż zespół. W teorii, mniej rąk do pracy, mniej godzin w tygodniu. W praktyce liczy się coś innego: ile czasu faktycznie idzie na budowanie, a ile na koordynację.
Bez daily standupów, retrospektyw i sprint planningu zostaje więcej czasu na faktyczne budowanie. Nie muszę pisać statusów dla project managera, nie czekam dwóch dni na code review, nie tłumaczę decyzji technicznych komuś, kto i tak nie będzie ich implementował. Decyzja, którą w zespole podjęłoby się na spotkaniu trwającym godzinę, u mnie zapada w kilka minut, bo nie trzeba nikogo przekonywać, wystarczy wiedzieć, że to dobry kierunek.
To nie znaczy, że pracuję bez procesu. Mam swoje rytuały, checklisty, sposoby na testowanie i wdrażanie. Różnica jest taka, że ten proces służy mi, a nie odwrotnie, mogę go zmienić z dnia na dzień, jeśli widzę, że coś nie działa, bez potrzeby ustalania tego z kimkolwiek.
Dla kogo to ma sens
Solo development nie jest uniwersalną odpowiedzią na każdy projekt. Przy naprawdę dużych, wieloletnich systemach, gdzie potrzeba równoległej pracy nad wieloma modułami, zespół ma sens, jedna osoba fizycznie nie ogarnie wszystkiego naraz.
Ale dla większości małych i średnich projektów, stron firmowych, aplikacji dla jednego klienta, MVP, które ma sprawdzić pomysł na rynku, solo development daje coś, czego zespół często nie jest w stanie zaoferować: szybkość decyzji, spójność techniczną od pierwszej do ostatniej linijki kodu i kogoś, kto naprawdę zna cały projekt, a nie tylko swój fragment.