Dwie główne usługi dla założycieli, których MVP powstało z AI lub na platformie no-code. Jeden cel: wziąć to, co wygenerowały Twoje narzędzia AI lub platforma no-code, i wdrożyć na produkcję — żeby było bezpieczne, skalowalne i łatwe w utrzymaniu. Zacznij od audytu. Do naprawy przechodzimy tylko wtedy, gdy audyt wykryje to, co zwykle wykrywa.
Pisemna ocena techniczna Twojego MVP — zbudowanego z AI lub w no-code — pod kątem wymagań produkcyjnych: bezpieczeństwa, skalowalności i łatwości utrzymania. Uporządkowana według ryzyka biznesowego, a nie estetyki kodu. Dokument zostaje Twój, niezależnie od tego, czy zlecisz mi naprawę, czy nie.
Przejmujemy kod stworzony z AI lub w no-code i dowozimy go jako prawdziwy produkt. Łatamy dziury w uwierzytelnianiu, naprawiamy błędy CORS, przyspieszamy wolne bazy danych, dokładamy brakującą infrastrukturę wdrożeniową. Robimy „ostatnie 20%", które AI pomija — CI/CD, monitoring, kopie zapasowe, disaster recovery.
Prawie każde zlecenie, które kończy się naprawą, zaczyna się od audytu. To najtańszy sposób, żeby dowiedzieć się, czy naprawa w ogóle ma sens — i ile będzie kosztować, jeśli ma. Audyt to 1–2 tygodnie pracy i dokument, który możesz wykorzystać, udostępnić albo zignorować. Naprawa to zlecenie na kilka tygodni z realnym zakresem. Nie chcesz tego kupować bez mapy.
Krótka rozmowa wstępna pokaże też, czy żadna z tych usług nie jest jeszcze tym, czego potrzebujesz — czasem właściwą odpowiedzią jest „najpierw zadbaj o trakcję" albo „Twój stack jest w porządku; oto co bym w nim zmienił".
Audyt, zawsze. Audyt powie Ci, czy naprawa jest właściwym następnym krokiem, czy masz tylko kilka konkretnych rzeczy do poprawienia. Wolę, żebyś dowiedział się, że potrzebowałeś tylko dwóch dni pracy, niż sprzedać Ci ośmiotygodniowe zlecenie, którego nie potrzebowałeś.
Tak, ale dopiero po krótkiej rozmowie o zakresie. Bez audytu naprawialibyśmy kod po omacku — a to prowadzi albo do zawyżenia zakresu (drogo dla Ciebie), albo do przeoczenia krytycznych problemów (źle dla nas obu). Audyt to niewielki koszt na start, dzięki któremu naprawa jest tańsza i lepiej dobrana do realnych potrzeb.
Dokument i tak należy do Ciebie, a to, co zrobisz dalej, to Twoja decyzja. Jeśli to krytyczny problem z bezpieczeństwem, powiem Ci o tym jasno i bez zwłoki. Jeśli to góra drobniejszych usterek, przejdziemy przez nie razem i ustalimy, które naprawdę warto naprawić — nie wszystko, co nie jest idealne, trzeba poprawiać już teraz.
Po naprawie masz dwie opcje: przekazuję projekt Twojemu zespołowi wraz z pisemną dokumentacją, albo zostaję na 3–6 miesięcy jako inżynier na część etatu, dopóki kogoś nie zatrudnisz. Nie wciskam długoterminowych umów na utrzymanie — moim celem jest stać się zbędnym.
To moja specjalność, ale podejmuję się też naprawy kodu po wykonawcach, którzy odeszli, po małych agencjach albo po pierwszych programistach z firmy, którzy poszli dalej. Wspólny mianownik to „nikt z obecnego zespołu nie umie się połapać w tym kodzie" — nie zaś konkretne narzędzie, którym go napisano.
Bezpłatnie. 30 minut. Opowiedz mi, co robi Twoja aplikacja i co w niej szwankuje. Powiem Ci szczerze, która usługa — o ile którakolwiek — jest właściwym kolejnym krokiem w Twojej sytuacji.
Umów bezpłatną rozmowę →