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 robić się dziwniej.
Brzmi znajomo? To kształt zlecenia.
W zleceniu naprawy przejmuję odpowiedzialność za pracę techniczną. Czytam Twój kod tak, jak czytałbym kod projektu, do którego właśnie zostałem zatrudniony — szybko, ale dokładnie. Priorytetyzuję według ryzyka biznesowego. Potem naprawiam.
Praca odbywa się w przejściach posortowanych według ryzyka, nie jako jedno wielkie przepisywanie. Widzisz działający postęp co kilka dni; nic typu „znikamy na trzy miesiące i wracamy z nową aplikacją". Każde przejście wdraża się niezależnie, przetestowane, w prawdziwym środowisku. Większość napraw rozwija się w tej kolejności:
Zakres nie jest sztywny — jeśli Twoja sytuacja wymaga wariantu domyślnego, określamy go odpowiednio. Ale domyślny zakres to miejsce, gdzie ląduje 80% napraw.
Zawsze. Jeśli jeszcze nie miałeś u mnie audytu, robimy audyt najpierw. Naprawa bez audytu to lot na ślepo — albo przeszacujemy (drogie dla Ciebie), albo pominiemy coś krytycznego (złe dla nas obu). Audyt też konkretyzuje zakres naprawy.
Zbudowany na bazie logu znalezisk audytu. Akceptujesz zakres, kolejność priorytetów i harmonogram przed rozpoczęciem jakiejkolwiek pracy. Stała cena, stały zakres.
Praca odbywa się w 3–5 odrębnych przejściach, każde wdrażane niezależnie w 1–2 tygodnie. Dostajesz postęp, który możesz zweryfikować co kilka dni — bez długich ciemnych okresów.
Aplikacja działa. Monitoring włączony. Backupy przetestowane. Dokumentacja napisana. Demonstruję, że każda z tych rzeczy działa, zanim zamkniemy projekt.
Dwie opcje: albo do Twojego zespołu (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 ląduje w 6–8 tygodni. Dostaniesz zobowiązanie do harmonogramu przed rozpoczęciem pracy.
Wycena per zlecenie, nie per godzina. Audyt produkuje konkretną listę znalezisk; wyceniamy naprawę względem tej listy. Dostaniesz stałą liczbę i stały harmonogram przed rozpoczęciem pracy. Jeśli zlecenie musi się rozszerzyć, robimy re-scope razem — bez niespodziewanych faktur w trakcie projektu.
Co wpływa na liczbę: rozmiar kodu, ile ze stacku wymaga naprawy, pilność i czy zlecenie kończy się czystym przekazaniem, czy przechodzi w tymczasowe ustalenia fractional. Wszystko ustalamy na rozmowie zapoznawczej.
Jest Twój. Naprawa dostarcza kod, który Twój następny inżynier może utrzymywać beze mnie. Pisemny dokument przekazania idzie razem. Jeśli chcesz, żebym był dostępny po dostawie na tymczasowy okres, podczas gdy kogoś zatrudniasz, to osobne zlecenie — nie zależność.
Nie. Przepisywanie to zwykle zła odpowiedź — jest drogie, trwa dłużej niż planowano i często nie naprawia podstawowego problemu. Naprawa poprawia zepsute części i zostawia działające w spokoju. Jeśli konkretny moduł naprawdę wymaga wymiany, wyceniamy to jako nazwane zlecenie, a nie ogólne 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.
Fractional zlecenia technicznego cofoundera są dostępne po udanej naprawie. To zazwyczaj 3–6-miesięczne tymczasowe ustalenie, gdzie zostaję part-time, podczas gdy rekrutujesz senior engineera lub CTO na pełen etat. Nie stałe zobowiązanie po żadnej stronie.
Silna ekspertyza w PHP (Symfony, Doctrine), Node.js, TypeScript, React, AWS (ECS, Lambda, RDS, SQS, SNS), Docker, Terraform. Naprawiałem aplikacje zbudowane z Supabase, Firebase, Vercel i większości narzędzi no-code. Jeśli Twój stack jest poza tymi obszarami, powiem Ci szczerze na rozmowie zapoznawczej, czy jestem właściwym ratownikiem dla 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 wyceniane oddzielnie od standardowej naprawy. Migracja z no-code do nowego kodu to inna forma zlecenia — obejmuje projektowanie nowej architektury, migrację danych i plan cutover. Ten sam audit-first approach jednak: zaczynamy od rozmowy zakresowej i audytu tego, z czego się przenosisz.
Want to see what an engagement like this looks like in practice? Read a real case study →
Bezpłatnie. 30 minut. Powiedz mi, co się psuje, co jest na szali i kiedy. Powiem Ci, czy naprawa to właściwy ruch — czy może audyt najpierw ma więcej sensu dla Twojej sytuacji.
Umów bezpłatną rozmowę →