MVP aplikacji, w którym oddaliśmy jedną piątą zakresu: Vertom AI

Vertom AI to platforma SaaS, w której agent głosowy prowadzi rozmowy telefoniczne z leadami, a setter AI odpowiada na wiadomości na Facebooku i Instagramie i umawia spotkania. Zbudowaliśmy jej pierwszą wersję: MVP aplikacji obejmujące panel, logikę rozmów i kampanii, integracje z usługami zewnętrznymi oraz warstwę danych. Platforma jest publicznie dostępna od września 2026.

Najważniejsza decyzja projektu zapadła, zanim podpisaliśmy umowę, i dotyczyła silnika rozmowy głosowej. Zamiast namawiać na większy zakres u nas, potwierdziliśmy, że gotowy zewnętrzny dostawca to trafny wybór na tym etapie. Około jedna piąta zakresu, który mógł zostać u nas, oparła się właśnie na tym komponencie. Kilka tygodni później ta decyzja zdała egzamin inaczej, niż ktokolwiek się spodziewał.

Jeśli budujesz pierwszą wersję własnego produktu, znasz pytanie, na które ten tekst odpowiada: skąd mam wiedzieć, że wykonawca doradzi mi to, co jest dobre dla produktu, a nie to, co powiększa jego zakres. Deklaracją tego nie rozstrzygniemy. Pokazujemy przebieg jednego projektu.

Z czym klient przyszedł

Klient przyszedł z listą funkcji i decyzją, że buduje własny produkt. Konkretny zakres i user stories, czyli opisane po ludzku scenariusze, które system ma obsłużyć, powstały już w projekcie, w iteracyjnej pracy warsztatowej. Po stronie klienta ktoś na bieżąco pilnował strony technicznej, co nam odpowiadało: rzeczowy nadzór po drugiej stronie stołu skraca dyskusje o tym, czy coś działa, bo obie strony patrzą na te same kryteria odbioru.

Nie zaproponowaliśmy, żebyśmy zbudowali silnik rozmowy sami

Silnik rozmowy głosowej mogliśmy zbudować sami. Mamy do tego kompetencje, a większy zakres oznaczałby większą fakturę. Zamiast tego potwierdziliśmy, że słuszniejszym wyborem na tym etapie jest gotowy komponent od sprawdzonego zewnętrznego dostawcy, a u nas zostaje logika, integracje, panel i dane.

Powód nie zmienia się od projektu do projektu. Przy pierwszej wersji produktu buduje się to, czego jeszcze nie ma na rynku, a resztę bierze się z półki. Silnik rozmowy stoi na tej półce w kilku sprawdzonych wariantach, więc pisanie własnego zjadłoby harmonogram na długo przed tym, zanim ktokolwiek sprawdziłby, czy produkt jest komuś potrzebny. Własny silnik oznacza też odpowiedzialność za każdy błąd w każdej rozmowie, przy hipotezie biznesowej, której nikt jeszcze nie potwierdził.

Konsekwencja tej decyzji jest policzalna: około jedna piąta zakresu, który mógł zostać u nas, oparła się na gotowym komponencie. Ten sam mechanizm opisaliśmy wcześniej, jeszcze bez nazwy projektu, we wpisie o tym, kiedy wykonawca odradza własny zakres. Nazwy dostawcy nie podajemy, bo taka jest granica ustalona z klientem.

W jeden dzień przepięliśmy ten sam silnik na innego dostawcę

Wybór gotowego dostawcy nie jest wyborem raz na zawsze. Na start postawiliśmy na jednego dostawcę silnika rozmowy. Po kilku tygodniach okazało się, że nie spełnia on wymagań biznesowych klienta, więc przepięliśmy tę warstwę na zupełnie innego.

Zajęło to około jednego dnia. Aplikacja działała cały czas, a reszty systemu nie trzeba było ruszać, bo od początku budowaliśmy ją tak, żeby dało się wymienić dostawcę silnika bez przepisywania wszystkiego naokoło.

To jest konsekwencja tej samej decyzji sprzed podpisania umowy, nie osobny wyczyn. Projekt, który ma szybko reagować na to, co mówi rynek, powinien być zaprojektowany tak, żeby zmiana dostawcy była zadaniem na dzień, a nie na miesiąc.

Co obejmowało MVP aplikacji, a czego w nim świadomie nie było

Pierwsza wersja objęła to, z czym klient przyszedł, docięte do postaci, którą dało się zbudować i odebrać etapami: panel dla zespołu klienta, logikę rozmów i kampanii, integracje z usługami zewnętrznymi i warstwę danych. Świadomie nie było w niej jednej rzeczy. Własny silnik rozmowy pisany od zera to nie luka w produkcie, tylko odłożona inwestycja, która czeka na dowód, że jest za co ją podejmować.

Jak oddzielamy pierwszą wersję produktu od wszystkiego, co może poczekać, opisujemy osobno we wpisie o tym, co musi mieć minimum viable product.

Jak powstawała platforma SaaS: dwa etapy i tygodniowe sprinty

Prace szły w tygodniowych sprintach, z cotygodniowym spotkaniem statusowym, na którym klient widział działającą wersję zamiast raportu. Całość podzieliliśmy na dwa etapy. Każdy miał odbiór dwustopniowy: najpierw środowisko testowe, na którym klient przeprowadzał testy akceptacyjne, potem produkcja i okres stabilizacji, po którym etap uznaje się za zamknięty. Dzięki temu „działa” nie było kwestią uznania, tylko listą kryteriów sprawdzonych dwa razy.

Najwolniejszym elementem takich projektów nie jest pisanie kodu, tylko weryfikacja integracji po stronie zewnętrznych dostawców, czyli ich zgoda na dostęp aplikacji do danych użytkownika. Tego procesu nie przyspieszymy ani nie ominiemy, u nas ani u żadnego wykonawcy. Możemy tylko ułożyć harmonogram tak, żeby zegar dostawców szedł równolegle z naszym, więc funkcje wymagające weryfikacji poszły pierwsze.

Do kogo należy kod, infrastruktura i rachunki za AI

Kod trafiał do repozytorium, do którego klient miał dostęp od pierwszego dnia prac, a prawa majątkowe przechodzą na niego wraz z zapłatą za etap. Infrastruktura działa na koncie chmurowym klienta, a konta usług zewnętrznych są założone na niego, nie na nas. Za modele AI klient płaci dostawcom bezpośrednio, bez naszej marży, więc widzi każdy rachunek. Gdyby jutro zakończył z nami współpracę, zostaje z działającym systemem, kodem i dokumentacją, a nie z licencją na cudzy produkt.

Jak wygląda współpraca po wdrożeniu

Platforma jest publicznie dostępna od września 2026, a Vertom jest u nas w opiece utrzymaniowej. W zespole, który ją prowadzi, jest osoba, która system budowała, nie przypisany opiekun z rotacji. Na kod dajemy 12 miesięcy gwarancji także wtedy, gdy klient opieki nie wybiera: błędy z naszej pracy naprawiamy bezpłatnie.

Ile płaci Vertom, nie napiszemy, bo to sprawa klienta. Punkt wejścia naszej oferty jest jawny: pierwszy zakres MVP z AI zaczyna się od 35 000 zł netto, a przed umową są warsztaty za 1 500 zł netto za dzień, odliczane od ceny projektu. Utrzymanie po wdrożeniu zaczyna się od 3 875 zł netto miesięcznie i policzysz je w kalkulatorze.

Czego ten projekt nie dowodzi

Nie dowodzi, że znamy wyniki Vertom: liczby użytkowników, przychody i skuteczność kampanii należą do klienta i nie pojawią się w naszych materiałach. Nie dowodzi też, że w każdym projekcie zostawiamy sobie mniejszy kawałek zakresu. W większości nic nie ma do oddania, a przy potwierdzonej hipotezie i produkcie z użytkownikami budowa własnego silnika bywa dokładnie tym, co trzeba zrobić. I nie jest to tekst dla każdego: jeśli szukasz najtańszego wykonawcy, nie jesteśmy nim.

Dla kogo ten model się sprawdza

Ten model pracy jest dla founderów, którzy budują pierwszą wersję produktu i chcą sprawdzić rozmowę o zakresie, zanim podpiszą umowę. Zaczynamy od warsztatów: wychodzisz z nich z zakresem, makietami przepływów i kryteriami odbioru na papierze, a ten dokument jest Twój także wtedy, gdy wybierzesz innego wykonawcę. Zasada z tego projektu obowiązuje w każdym: najpierw budujemy jedną rzecz, którą da się sprzedać, a resztę dokładamy z tego, co powiedzą pierwsi klienci.

Jeśli chcesz porównać swój zakres z tym, co obejmuje MVP z AI, zacznij tam. A jeśli wolisz rozmowę, umów ją tutaj: trwa 45 minut, odbiera współzałożyciel, bez prezentacji sprzedażowej.