Budowa code2saas z AI: panel powstawał, a najważniejsze pytania pozostawały otwarte

Można mieć stronę oferty, panel uczestnika i rozpisaną metodę budowania produktów, a nadal nie wiedzieć, czy ktokolwiek za to zapłaci. Trochę jak dom z gotowymi meblami, do którego jeszcze nikt nie chciał się wprowadzić. Taką sytuację pokazał przegląd code2saas z 28 września 2026 roku.

W dokumentacji były już opisy funkcji, zasad pracy i planowanego programu. Powstał kod aplikacji. Jednocześnie karta produktu (dokument z planem produktu) odnotowywała zero rozmów walidacyjnych, czyli rozmów sprawdzających, czy problem w ogóle istnieje, zero płacących klientów i brak ustalonego kosztu utrzymania uczestnika.

Ten etap łatwo przeoczyć przy pracy z AI. Każda nowa funkcja daje widoczny efekt od razu. Odpowiedź na pytanie, czy ktoś w ogóle potrzebuje całości, wymaga zupełnie innej pracy: rozmów, a nie kodu.

Ten tekst opisuje udokumentowany stan i testy z 28 września. Nie pokazuje wyniku sprzedaży ani historii rentownego biznesu, tylko to, co ujawniło użycie własnej metody na własnym projekcie. Stan na 8 października 2026: strona code2saas.pl działa i przyjmuje zgłoszenia do programu Builder, a panel uczestnika pozostaje zamknięty.

Co budowaliśmy i dla kogo

Code2saas nie powstał w próżni. Od 2014 roku przeszedłem drogę od zleceniodawcy, który włożył około 500 tys. zł w projekty IT bez złotówki przychodu, przez dwa lata SEO i stron na WordPressie, po Archiplaner i Ofertodom, które działają u ludzi. Najważniejsza lekcja z tej drogi: działający kod to dopiero połowa sukcesu. Ten tekst pokazuje, że nawet z tą wiedzą łatwo znów wpaść w budowanie zamiast rozmów.

Code2saas rozwijamy dla osób, które chcą budować z AI aplikacje na sprzedaż, także bez wcześniejszej wiedzy programistycznej. Pomoc ma obejmować decyzje o produkcie, pracę nad aplikacją i sprawdzanie rezultatów.

W testowanej wersji Pracownia — panel, w którym uczestnik widzi plan i postęp — przechowywała informacje o projekcie, decyzjach i wynikach sprawdzeń. Agent uczestnika pracował z plikami projektu, a połączenie z panelem pozwalało przekazać wybrane informacje o postępie. Prowadzenie i przegląd pracy miał zapewniać prowadzący programu.

Założenie było konkretne: uczestnik powinien widzieć jeden sensowny następny krok i wiedzieć, co musi zostać sprawdzone. Z perspektywy właściciela powstawało jednak ważniejsze pytanie: czy ludzie uznają taką pomoc za potrzebną i będą z niej korzystać?

Sprawdziliśmy plan tak samo, jak mieli robić to uczestnicy

Metoda zawierała listę warunków dla planu produktu: opis problemu, hipotezy, rozmowy z odbiorcami, zakres pierwszej wersji, koszty i kryteria dalszej pracy. Nazywamy ją bramą B0. Brama to zestaw sprawdzeń przed przejściem dalej — jak odbiór techniczny przed wprowadzeniem się do mieszkania.

Zapisany wynik tego przeglądu wyniósł 6 punktów spełnionych i 9 niespełnionych spośród 15 sprawdzanych. To wynik wewnętrznej oceny udokumentowanej przez agenta, nie niezależny certyfikat.

Były materiały opisujące odbiorcę i hipotezy. Był rejestr decyzji. Brakowało natomiast przeprowadzonych rozmów, decyzji o kontynuacji wynikającej z ich rezultatów, konkretnej ceny oraz kosztu na uczestnika. Nie ustalono też wszystkich granic budżetu czasu.

Wynik nie przekreślał pomysłu. Pokazywał, że prace nad aplikacją wyprzedziły sprawdzenie części założeń biznesowych. Uczciwe zapisanie tego faktu było potrzebne, żeby kolejne funkcje nie przesłoniły braków.

Narzędzie wskazywało krok, ale niekoniecznie najważniejszy

Test własnej metody ujawnił także konkretny problem w aplikacji. Wskazanie następnego kroku opierało się na pierwszym niespełnionym punkcie według numeru. Nie uwzględniało kolejności zadań zapisanej w planie pracy.

To podstępny błąd. Ekran pokazywał rozsądnie brzmiące zadanie, a mimo to pomijał wcześniejszą decyzję właściciela. Jak nawigacja, która prowadzi do pierwszego adresu z listy zamiast do tego, który zaplanowałeś na dziś. Użytkownik potrzebował wiedzieć, od czego zacząć przy swoim projekcie.

Poprawiliśmy to: teraz panel bierze pierwsze otwarte zadanie z planu danego etapu, w kolejności ustalonej przez właściciela. Rozróżnia też zadanie dla człowieka od takiego, które może wykonać agent. Tak działa kod, który przejrzeliśmy przy pisaniu tego tekstu.

Wniosek dla twórcy aplikacji jest praktyczny: sprawdź, czy podpowiedź pomaga wykonać właściwą pracę. Samo wyświetlenie komunikatu i brak błędu programu jeszcze o tym nie świadczą.

Własny projekt ujawnił założenia zaszyte w narzędziach

Skrypt rozpoznający stan aplikacji nie uwzględniał początkowo, że jej kod może znajdować się w podfolderze. W naszym projekcie właśnie tak było. Poprawiliśmy go: teraz sam odnajduje właściwy katalog albo można go wskazać ręcznie.

Pojawiła się też niespójność materiałów: starsze opisy znały mniej etapów sprawdzania niż aktualna metoda. Uczestnik korzystający z dwóch różnych instrukcji mógł więc otrzymać różne wskazówki.

To nie są efektowne funkcje do pokazania na stronie oferty. Są jednak istotne dla osoby, która ma wykonać zadanie bez znajomości całej historii projektu. Jeśli instrukcja działa tylko przy domyślnym układzie plików albo wymaga wiedzy autora, trzeba to wykryć przed szerszym użyciem.

Zielony wynik techniczny miał ograniczony zakres

Osobny raport z tego samego dnia opisuje przegląd jakości kodu. Początkowo minimum spełniało 8 z 19 punktów. Po poprawkach i przeglądzie zmian ten sam raport pokazał 19 z 19.

W raporcie opisano między innymi porządkowanie wspólnych funkcji, usuwanie nieużywanego kodu i uzupełnianie sprawdzeń. Wskazano też błąd formatowania tekstu wykryty przez test.

To dokumentuje poprawę w jednym obszarze. Nie mówi nic o popycie, skuteczności nauczania ani opłacalności programu. Raport techniczny to przegląd samochodu, a rozmowa z klientem to sprawdzenie, czy ktoś chce nim jechać. Oba są potrzebne i jedno nie zastąpi drugiego.

Czego ten przypadek nie pozwala policzyć

Dokumentacja z tego etapu nie zawiera pełnego kosztorysu ani ewidencji czasu, które pozwoliłyby uczciwie podać koszt zbudowania code2saas. Nie ma też wyniku płatnego pilotażu pozwalającego policzyć obsługę uczestnika.

Nie podajemy więc szacunku pod pozorem rzeczywistego rachunku. Koszty trzeba zbierać osobno: narzędzia, infrastruktura, przygotowanie materiałów, rozmowy, przeglądy projektów i pomoc, kiedy uczestnik utknie. Sposób stworzenia takiego zestawienia pokazuje artykuł o budżecie aplikacji.

Ten brak danych również jest wynikiem przeglądu. Właściciel potrzebuje go zobaczyć, zanim zacznie planować skalę sprzedaży.

Co możesz sprawdzić u siebie

Otwórz projekt i zrób dwie krótkie listy. Na pierwszej zapisz działające elementy: formularz, zapis, logowanie, płatność lub inna czynność. Na drugiej zapisz dowody biznesowe: rozmowy o problemie, próby z docelowymi odbiorcami, płatne użycie, powroty i koszt obsługi.

Porównaj je. Jeżeli pierwsza szybko rośnie, a druga pozostaje pusta, warto zaplanować sprawdzenie pomysłu z ludźmi. Jeśli masz zainteresowanie i prototyp, przejdź scenariusze przed udostępnieniem klientom.

Przy każdym zadaniu dopisz wykonawcę. Agent może przygotować zestawienie albo test. Decyzja o budżecie, rozmowa z odbiorcą i przyjęcie zobowiązania wobec klienta pozostają po stronie właściciela.

Code2saas ma pomagać uporządkować właśnie taką pracę. Wyślij zgłoszenie do Buildera, jeśli chcesz budować ją na sprzedaż oraz uczyć się samodzielnego prowadzenia projektu z AI. Osobiście prowadzę małą grupę, do której przyjmuję po rozmowie.

Jeszcze nie teraz? Zostaw e-mail na liście — napiszemy, gdy ruszy kolejny nabór.