Przejmujemy Twoje MVP tworzone przez AI lub no-code, naprawiamy co zepsute i dostarczamy je na produkcję jako prawdziwy, utrzymywalny produkt. Nie przepisywanie. Nie łatanie. Praca inżynierska, która sprawia, że Twoja aplikacja jest naprawdę gotowa dla płacących klientów.
Twoje MVP działało pierwszego dnia. Potem zaczęło dziać się coraz dziwniej.
Brzmi znajomo? To właśnie typowe zlecenie.
W zleceniu naprawy biorę na siebie całą pracę techniczną. Czytam Twój kod tak, jak czytałbym projekt, do którego właśnie dołączyłem — szybko, ale dokładnie. Ustalam priorytety według ryzyka biznesowego. Potem naprawiam.
Pracujemy w etapach uszeregowanych według ryzyka, a nie jako jedno wielkie przepisywanie. Widzisz realne postępy co kilka dni; żadnego „znikamy na trzy miesiące i wracamy z nową aplikacją". Każdy etap trafia na produkcję niezależnie, przetestowany, w prawdziwym środowisku. Większość napraw przebiega w tej kolejności:
Zakres nie jest sztywny — jeśli Twoja sytuacja wymaga odstępstwa od wariantu domyślnego, ustalamy go odpowiednio. Ale to właśnie w domyślnym zakresie mieści się 80% napraw.
Zawsze. Jeśli jeszcze nie robiłeś u mnie audytu, zaczynamy od audytu. Naprawa bez audytu to działanie po omacku — albo przeszacujemy zakres (drogo dla Ciebie), albo pominiemy coś krytycznego (źle dla nas obu). Audyt też nadaje konkretny kształt zakresowi naprawy.
Powstaje na podstawie listy znalezisk z audytu. Akceptujesz zakres, kolejność priorytetów i harmonogram, zanim ruszy jakakolwiek praca. Stała cena, stały zakres.
Praca przebiega w 3–5 odrębnych etapach, każdy wdrażany niezależnie w 1–2 tygodnie. Co kilka dni dostajesz postęp, który możesz sam zweryfikować — bez długich okresów ciszy.
Aplikacja działa. Monitoring włączony. Backupy przetestowane. Dokumentacja gotowa. Zanim zamkniemy projekt, pokazuję na żywo, że każda z tych rzeczy działa.
Dwie opcje: albo Twojemu zespołowi (z dokumentacją + 2 tygodnie wsparcia przez Slack w cenie), albo zostaję jako fractional part-time engineer na 3–6 miesięcy, dopóki kogoś nie zatrudnisz. Twoja decyzja.
Harmonogram: 4 do 12 tygodni. Większość napraw mieści się w 6–8 tygodniach. Zanim ruszy praca, dostaniesz zobowiązanie co do harmonogramu.
Wycena za zlecenie, nie za godzinę. Audyt daje konkretną listę znalezisk; naprawę wyceniamy względem tej listy. Stałą kwotę i stały harmonogram dostaniesz przed rozpoczęciem pracy. Jeśli zlecenie musi się rozszerzyć, wspólnie ustalamy nowy zakres — bez niespodziewanych faktur w trakcie projektu.
Co wpływa na kwotę: rozmiar kodu, jak duża część stacku wymaga naprawy, pilność oraz to, czy zlecenie kończy się czystym przekazaniem, czy przechodzi w tymczasową współpracę fractional. Wszystko ustalamy na rozmowie zapoznawczej.
Jest Twój. Naprawa daje Ci kod, który kolejny inżynier utrzyma beze mnie. W komplecie dostajesz pisemny dokument przekazania. Jeśli chcesz, żebym po oddaniu projektu był dostępny przez jakiś czas, zanim kogoś zatrudnisz, to osobne zlecenie — a nie uzależnienie od mnie.
Nie. Przepisanie wszystkiego to zwykle złe rozwiązanie — jest drogie, trwa dłużej niż zakładano i często nie usuwa źródła problemu. Naprawa poprawia zepsute części, a działające zostawia w spokoju. Jeśli konkretny moduł rzeczywiście wymaga wymiany, wyceniamy go jako osobny, nazwany zakres pracy, a nie hurtowe przepisywanie.
Sam audyt dostarcza realnej wartości, nawet jeśli nigdy nie zrobisz naprawy. Możesz też zatrudnić mnie do pojedynczych znalezisk z audytu — tylko naprawa CORS, tylko przepisanie autentykacji, tylko konfiguracja CI/CD. Jest to szczególnie przydatne, gdy audyt odkrywa jeden lub dwa duże problemy, które możesz zaatakować niezależnie.
Po udanej naprawie dostępna jest współpraca w modelu fractional na zasadzie technicznego współzałożyciela. To zwykle tymczasowy układ na 3–6 miesięcy, w którym zostaję na część etatu, podczas gdy Ty rekrutujesz senior engineera lub CTO na pełen etat. Żadna ze stron nie wiąże się na stałe.
Mocno czuję się w PHP (Symfony, Doctrine), Node.js, TypeScript, React, AWS (ECS, Lambda, RDS, SQS, SNS), Dockerze i Terraformie. Naprawiałem aplikacje oparte na Supabase, Firebase, Vercel i większości narzędzi no-code. Jeśli Twój stack jest poza tymi obszarami, na rozmowie zapoznawczej powiem Ci szczerze, czy jestem odpowiednią osobą do tej sytuacji.
4 do 12 tygodni. Większość napraw ląduje w zakresie 6–8 tygodni. Dokładny harmonogram zależy od tego, co znajduje audyt i jak duże jest Twoje MVP. Dostajesz stałe zobowiązanie do harmonogramu przed rozpoczęciem pracy, nie otwarte zlecenie godzinowe.
Tak, ale wyceniam to oddzielnie od standardowej naprawy. Migracja z no-code do nowej bazy kodu to inny rodzaj zlecenia — obejmuje zaprojektowanie nowej architektury, migrację danych i plan przełączenia. Podejście jest jednak takie samo, z audytem na początku: zaczynamy od rozmowy o zakresie i audytu tego, z czego się przenosisz.
Chcesz zobaczyć, jak takie zlecenie wygląda w praktyce? Przeczytaj prawdziwe case study →
Bezpłatnie. 30 minut. Powiedz mi, co się psuje, co jest na szali i na kiedy. Powiem Ci, czy naprawa to właściwy ruch — czy może w Twojej sytuacji więcej sensu ma najpierw audyt.
Umów bezpłatną rozmowę →