Naprawa kodu AI — Dowieź to, co AI zaczęło
Przejmuję Twoje MVP tworzone przez AI lub no-code, naprawiam co zepsute i dostarczam 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.
Scenariusz, który sprowadza tu założycieli
Twoje MVP działało pierwszego dnia. Potem zaczęło dziać się coraz dziwniej.
- Funkcje, które kiedyś wdrażało się w godzinę, zajmują tydzień.
- Klient zgłasza coś, co nie powinno się wydarzyć — a Ty nie potrafisz ustalić, jak do tego doszło.
- AI nadal chętnie pisze kod. Ale każda nowa rzecz, którą dodaje, psuje coś, co działało wcześniej.
- Nie śpisz po nocach, bo nie daje Ci spokoju pytanie „co jeszcze tam nie gra?“
- Wykonawca odszedł (albo został zwolniony), a nikt z obecnego zespołu nie potrafi czytać tego kodu.
- Wyrosłeś z Bubble / Webflow / Supabase Edge Functions i musisz się z nich przenieść, nie psując produktu.
Brzmi znajomo? To właśnie typowe zlecenie.
Audyt to dokument. Naprawa to kod.
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:
Co jest w cenie, co jest extra
W cenie domyślnie
- Pełne zapoznanie się z istniejącym kodem i ocena jego stanu
- Naprawa bezpieczeństwa — autentykacja, autoryzacja, sekrety, walidacja danych wejściowych
- Pipeline wdrożeniowy — domena, HTTPS, separacja środowisk, CI/CD, monitoring, backupy
- Uporządkowanie bazy danych — indeksy, migracje, wydajność, ograniczenia integralności
- Wzmocnienie integracji zewnętrznych (webhooki Stripe, dostarczalność e-maili, dostawcy logowania)
- Refaktoryzacja krytycznych ścieżek pod kątem utrzymywalności
- Pisemny dokument przekazania dla kolejnego inżyniera
Poza ceną domyślną
- Budowa nowych funkcji poza tym, co konieczne do bezpiecznego wdrożenia
- Przeprojektowanie wyglądu front-endu
- Pełna migracja na nową platformę (np. Bubble → Node.js) — wyceniana oddzielnie jako projekt migracji
- Stała rola fractional CTO / długoterminowa opieka techniczna — dostępna jako kontynuacja
- Tworzenie aplikacji mobilnych
- Praca nad produktem / UX
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.
Przebieg współpracy
1. Najpierw audyt
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.
2. Plan 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.
3. Naprawa w etapach uszeregowanych według ryzyka
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.
4. Odbiór na produkcji
Aplikacja działa. Monitoring włączony. Backupy przetestowane. Dokumentacja gotowa. Zanim zamkniemy projekt, pokazuję na żywo, że każda z tych rzeczy działa.
5. Przekazanie
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.
Naprawa jest dla Ciebie, jeśli…
- Masz MVP z płacącymi klientami lub podpisanym pilotem. W przeciwnym razie najpierw skup się na zdobyciu trakcji.
- Zrobiłeś audyt i wiesz, że to nie kilka drobnych poprawek na jedno popołudnie — jest tu realna praca inżynierska do wykonania.
- Nie możesz szybko zatrudnić senior dewelopera i nie chcesz spędzić kolejnych sześciu miesięcy na rekrutacji.
- Wolisz, żeby ktoś w całości zdjął z Ciebie ciężar techniczny, byś mógł skupić się na sprzedaży, produkcie lub pozyskiwaniu finansowania.
- Zbliża się runda finansowania, kontrakt z dużym klientem albo audyt regulacyjny, a Twój obecny kod tego nie wytrzyma.
Naprawa nie jest dla Ciebie, jeśli…
- Nie masz jeszcze zwalidowanego produktu. Naprawa to zlecenie na wiele tygodni — nie opłaca się przy niezwalidowanym pomyśle.
- Chcesz w nieskończoność pisać kod narzędziami AI, a ja mam „sprzątać po nich”. Tak się nie umawiamy. Naprawiam kod; nie niańczę promptów.
- Masz do naprawienia tylko jedną czy dwie konkretne rzeczy (np. samą konfigurację CORS). Wtedy zatrudnij mnie do tych pojedynczych znalezisk — taniej i szybciej.
Jak wygląda wycena
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.
Chcesz zobaczyć, jak takie zlecenie wygląda w praktyce? Przeczytaj prawdziwe case study →
Pytania, które założyciele zadają przed umówieniem się
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.
Umów rozmowę zapoznawczą
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ę →