O czym jest ten film
- Autor zbudował działający klon Calendly (nazwany Snag Time) w tydzień, przy pomocy zaledwie kilku promptów do agenta kodującego.
- Aplikacja ma logowanie, panel z przeglądem rezerwacji, ustawienia workspace’u, zapraszanie członków zespołu z rolami i pełną personalizację brandingu.
- Typy wydarzeń są w pełni konfigurowalne: kolor, opis, link, lokalizacja, bufory, zakres dat i własne pytania do rezerwującego.
- Dostępność synchronizuje się na żywo z prawdziwym kalendarzem Google — blokada w kalendarzu natychmiast znika z listy wolnych terminów.
- Zintegrowany Stripe pozwala prowadzić płatne konsultacje; w filmie pokazany jest przepływ płatności w środowisku sandboxowym.
- Proces budowy oparto na jednym dużym promptcie z czterema fazami: badanie, planowanie, budowa, testowanie — z pętlą testuj–napraw–testuj.
- Testowanie prowadził rój około 50 agentów klikających po aplikacji i szukających błędów; ta pętla trwała kilka dni.
- Agenty nie wychwyciły problemów z doświadczeniem użytkownika — poprawki UX, rebranding i optymalizację wydajności autor musiał zlecić ręcznie.
- Twarde liczby: 5 dni pracy, 334 godziny działania agentów, 76 unikalnych subagentów, 32 mld tokenów wejściowych, 47 mln wyjściowych, 15 tys. dolarów wartości inferencji.
- Autor otwarcie studzi zapał: to działa dla narzędzia wewnętrznego, ale to nie to samo, co zbudowanie i utrzymanie skalowalnego produktu SaaS.
Redakcyjne tłumaczenie
Punkt wyjścia
Właśnie zbudowałem klon Calendly i jego utrzymanie nic mnie nie kosztuje. Calendly wyceniane jest na jakieś 3 miliardy dolarów, a konkurenci w rodzaju Cal.com na mniej więcej 150 milionów, przy dziesiątkach milionów pozyskanego finansowania. Mnie zajęło tydzień, żeby odtworzyć rdzeń tej funkcjonalności za pomocą kilku promptów — i teraz mam to za darmo.
W tym materiale pokażę, co konkretnie zbudowałem, oddam to za darmo, wytłumaczę, jak samemu to postawić, i powiem dokładnie, ile mnie to kosztowało.
Co widzi użytkownik: przegląd aplikacji
Aplikacja nazywa się Snag Time. Trzeba się zalogować — konto już mam, więc wchodzę od razu. Na ekranie głównym mamy przegląd z moim brandingiem; to jest mój workspace o nazwie Upet AI. Widzę nadchodzące rezerwacje, ich liczbę w tym miesiącu, liczbę zabookowanych godzin oraz opublikowane linki, czyli ile mam różnych typów wydarzeń. Poniżej lista nadchodzących spotkań, którą można rozwinąć po szczegóły, a każde spotkanie przełożyć albo odwołać. Kto korzystał z Calendly albo Cal.com, poczuje się jak u siebie — funkcjonalność jest ta sama.
W ustawieniach zmienię workspace, hasło, zdjęcie profilowe. Mogę zaprosić innych członków zespołu i nadać im uprawnienia — członka albo administratora. Ustawię też obrazek workspace’u, kolory, opisy i tym podobne rzeczy.
(Informacja dodatkowa: Calendly i Cal.com to narzędzia do samodzielnego umawiania spotkań — udostępniasz link, druga strona sama wybiera wolny termin z twojego kalendarza. Cal.com jest ich odpowiednikiem o otwartym kodzie źródłowym.)
Typy wydarzeń i uruchomienie lokalne
Warto pokazać, czym jest typ wydarzenia i jak działa. W zakładce typów wydarzeń mam „revenue strategy session”, mam test — większość powstała w trakcie testowania. Kilka zrobiłem sam, na przykład płatną sesję scopingową. Tak, podłączyłem Stripe, więc można u mnie rezerwować płatne rozmowy. Jest też zwykła rozmowa strategiczna.
Jedna uwaga: wszystkie te linki mają w adresie „localhost”, bo w tej chwili wszystko chodzi u mnie lokalnie. Żeby faktycznie wysyłać linki klientom i przyjmować rezerwacje, trzeba to wypchnąć na publiczną domenę — choćby na Vercel — i wtedy całość działa w pełni. Konfiguracja u siebie sprowadza się do podłączenia konta Google, bazy danych backendowej i konta Stripe.
Jeśli chcecie to dostać za darmo, wystarczy wejść do mojej darmowej społeczności na Skool — link w opisie. Zakładka „classroom”, dalej „all YouTube resources”. Znajdziecie tam kompletny przewodnik konfiguracji, który pozwala postawić wszystko w jeden dzień.
(Informacja dodatkowa: Vercel to popularna platforma hostingowa dla aplikacji frontendowych; „localhost” oznacza, że aplikacja działa wyłącznie na komputerze autora i nie jest dostępna z zewnątrz.)
Przepływ rezerwacji i synchronizacja z kalendarzem
Kopiuję link, otwieram nową kartę i wklejam. Widać opis, który sam ustawiłem — mogę go oczywiście zmienić. Branding jest mój, własny. Teraz wybieram datę i godzinę.
To jest podpięte pod mój prawdziwy kalendarz. Patrzymy na piątek: mogę zarezerwować tylko od 14 do mniej więcej 15, a potem od 16 do 16:30. Zaglądam do rzeczywistego kalendarza — cały jutrzejszy poranek jest zajęty, a potem blok od 15 do 16. Wszystko się zgadza. W przyszłym tygodniu nie ma nic poza dwiema rozmowami: w poniedziałek od 9 do 11. Wracam do linku rezerwacyjnego, wchodzę na poniedziałek i faktycznie przedział od 9 do 11 jest niedostępny.
Synchronizacja działa na żywo. Wstawiam teraz w poniedziałek duży blok od 13 do 18, nazwijmy go „busy”. Wracam do zakładki z rezerwacją, odświeżam — i wszystkie te godziny są już zablokowane.
Wybieram piątek i rezerwuję na 16:15. Przechodzę dalej, do ekranu z danymi. Wpisuję imię i przykładowy adres e-mail, który akurat jest prawdziwy, resztę pól wypełniam testowo. Mogę zrecenzować rezerwację. Ten ekran może zadawać więcej pytań — to się ustawia przy tworzeniu typu wydarzenia. Potwierdzam rezerwację i widzę ekran, który zobaczy osoba umawiająca spotkanie: powiadomienie z możliwością przełożenia albo odwołania.
Wracam do swojego kalendarza, piątek — jest rozmowa strategiczna z tym adresem e-mail. A tu jestem w skrzynce, na którą zapisałem się na tę rozmowę: zaproszenie trafiło do kalendarza i mogę je po prostu zaakceptować.
Edycja i tworzenie typów wydarzeń
Jak wygląda tworzenie albo edycja typu wydarzenia? Przy edycji klikam „edit” i zmieniam kolor, opis, link, nazwę, lokalizację oraz sposób działania dostępności — mogę dodać bufor między spotkaniami albo zakres dat. Bardzo podobnie do Calendly. Mogę też zmienić pytania zadawane przy rezerwacji. Dostajesz pełną kontrolę nad tym, ile typów wydarzeń potrzebujesz i co mają robić.
Tworzenie nowego wygląda praktycznie tak samo: nazwa, opis, link rezerwacyjny, czas i cała reszta. Decydujesz też, czy wydarzenie jest darmowe, czy płatne — a jeśli płatne, ustawiasz cenę i ludzie muszą zapłacić.
Płatności przez Stripe
Pokażę przepływ płatny. Wybieram środę przyszłego tygodnia, bo jest zupełnie wolna, i biorę slot na 10 rano. Idę dalej — ta sama osoba, wyraźnie bardzo zmotywowana, żeby coś ustalić.
Tu jedna dygresja, bo właśnie sobie przypomniałem jedną z ręcznych poprawek, które musiałem wprowadzić. Agenty przeklikały cały ten proces i po wielokrotnych testach nie znalazły żadnych błędów. Ale człowiek wchodzi na ekran podsumowania i myśli: „chcę wrócić do wyboru godziny, kliknę w ten pasek postępu u góry”. Tymczasem interfejs pierwotnie nie zakładał, że te przyciski są klikalne — dało się cofnąć wyłącznie strzałkami. Nie wiem jak wy, ale ja zawsze odruchowo klikam w pasek, a nie w małą strzałkę, która w ogóle nie przyciąga uwagi.
To jest właśnie ten rodzaj rzeczy, o których jeszcze powiem przy okazji reszty prac nad projektem. Wróciłem i przeprojektowałem doświadczenie użytkownika, bo choć agenty świetnie radziły sobie z wyszukiwaniem błędów, nie myślały o doświadczeniu tak, jak myśli człowiek. Nawet gdy je o to wyraźnie poprosiłem, przeoczyły coś takiego. Chcę to wyraźnie zaznaczyć, bo pamiętam moment, w którym pomyślałem: „to będzie znacznie lepsze doświadczenie użytkownika”.
Wracamy do płatności. System przenosi nas do linku Stripe, pokazuje się „confirming” i przechodzimy na inny adres. To jest środowisko sandboxowe, więc wpisuję kartę testową — żeby przejść na prawdziwe płatności, wystarczy podmienić klucze API na produkcyjne Stripe i wszystko działa. Stripe każe użyć tego numeru jako karty testowej, a w dwóch pozostałych polach można wpisać dowolną kombinację. To symuluje dokładnie to, co przechodzi użytkownik: wpisanie karty, płatność — i gotowe. Widzimy powiadomienie o płatnej sesji scopingowej z Nate’em w środę 2 września o 10 rano.
(Informacja dodatkowa: sandbox Stripe to tryb testowy — transakcje wyglądają realistycznie, ale żadne pieniądze nie zmieniają właściciela.)
Czego brakuje i dlaczego to nie przeszkadza
I to zasadniczo tyle. Interfejs jest naprawdę prosty. Przyznaję, że brakuje części funkcji automatyzacyjnych, które ma Calendly, ale to można bez trudu dorobić, skoro masz Codex albo Claude Code, które w pełni znają tę aplikację i wiedzą, co chcesz dodać. Automatyzacje możesz też zbudować bezpośrednio w środku.
Można oczywiście robić inne rzeczy: zmienić dostępność, jeśli chcesz pracować w soboty i niedziele, zmienić godziny pracy, strefę czasową, dodać wyjątki dla konkretnych dat albo urlop.
A skoro to teraz twoje, wystarczy powiedzieć: „zmień, jak to działa” albo „dodaj taką funkcję”. Kiedy coś w Snag Time cię uwiera — przez sposób, w jaki to zbudowałem — po prostu prosisz Codex albo Claude Code o rozbudowę, bo warstwa oprogramowania należy do ciebie.
Jak to powstało: pięć promptów w czterech fazach
Przejdźmy do tego, jak to zbudowałem i jak wyglądają statystyki. Zanim podam liczby, opowiem, co właściwie zrobiłem — bo wysłałem tak naprawdę tylko pięć promptów.
Zacząłem od jednego ogromnego promptu celu. W skrócie napisałem: klonujemy Calendly, chcę móc to uruchomić lokalnie i za darmo. Poprosiłem o pracę w czterech fazach: badanie, planowanie, budowa, testowanie. To potem weszło w pętlę — testowanie, budowa, znów testowanie i tak dalej.
Faza badawcza miała objąć Calendly i Cal.com: co ludzie w nich lubią, a czego nie znoszą. Te wnioski miały wejść do fazy planowania, gdzie mamy już listę pożądanych funkcji i projektujemy, jak realnie to wykonać — z subagentami, z bazą danych po stronie backendu, z integracjami. Kiedy plan był gotowy, agent zaczął budować i budował, i budował.
Potem uruchomiłem pętlę testową. Nie chciałem po zakończeniu budowy dostać zwykłego podsumowania zmian — chciałem, żeby przepuścić przez aplikację jakieś 50 agentów, którzy przejdą ścieżkę administratora, rejestracji, tworzenia typu wydarzenia. Przetestowali to za mnie tyle razy, że sam nie musiałem tam nawet wchodzić. Krążyli w pętli: budowa, wyszukiwanie błędów podczas testów, naprawa, znów testy, kolejne błędy, kolejne naprawy. Samo to trwało kilka dni. Uważam, że ta agentowa, autonomiczna pętla testowa jest po prostu rewelacyjna.
(Informacja dodatkowa: „prompt celu” to w tej praktyce jedna długa instrukcja opisująca cel i etapy pracy, zamiast serii drobnych poleceń — agent sam rozbija ją na zadania i deleguje subagentom.)
Cztery rzeczy, które musiałem zrobić ręcznie
Potem zabrałem się do roboty sam, bo to, co wróciło, mi się nie spodobało. Aplikacja wyglądała bardzo „vibe-codowo”.
Pierwszą rzeczą był rebranding. Projekt nazwał się początkowo Tempo Cove — lokalnie w moim katalogu wciąż figuruje pod tą nazwą, bo tak sam się ochrzcił, a mnie to nie leżało. Zrobiłem rebranding na Snag Time i przy okazji trochę lepiej przeprojektowałem interfejs. Rebranding plus redesign, wyłącznie na podstawie mojego feedbacku.
Drugą rzeczą była kolejna porcja testów. Wyszło coś, czego agenty nie wychwyciły: aplikacja strasznie mulila. Nie wiem dlaczego, ale była wolna. Na samym linku rezerwacyjnym kursor się zacinał, pisanie było ociężałe, całość mało responsywna. Zrobiłem prompt celu: „potnij czasy ładowania, chcę 10 milisekund zamiast sekundy”. Agent wykonał sporo pracy nad płynnością i responsywnością serwisu.
Trzecia i czwarta rzecz to projektowanie. Wiem, że wciąż nie wygląda to świetnie — interfejs był dziwny, ale dziwne było też samo doświadczenie. Poprzestawiałem trochę przyciski. Nie jestem ekspertem od designu i to nadal nie jest nic olśniewającego, ale wierzcie mi: jest lepiej, niż było.
Chłodna ocena: to nie jest gotowy SaaS
Chodzi mi o to, co musiałem zrobić własnoręcznie. Tak, początkowy prompt celu był świetny. Tak, kilkoma promptami udało się zrobić ogrom pracy. Ale nie chcę deprecjonować tego, jak trudno zbudować i wyskalować produkt SaaS.
Jest ogromna różnica między zbudowaniem czegoś na użytek wewnętrzny małego zespołu a zbudowaniem czegoś, co ma się naprawdę skalować — dziesiątki tysięcy dolarów miesięcznie na inferencję i bazy danych, mnóstwo błędów, mnóstwo próśb o nowe funkcje. Nawet jeśli miałbym to wdrożyć wyłącznie u siebie, a chcę to zrobić, znajdę mnóstwo błędów i mnóstwo rzeczy, za które ja albo ktoś z mojego zespołu będzie musiał wziąć odpowiedzialność. To nie jest tak, że po kilku promptach masz coś, co przetrwa próbę czasu.
Liczby: czas, agenty, tokeny, koszt
Skoro nudniejsza część za nami, przejdźmy do statystyk.
Ile mi to zajęło? 5 dni i 5 godzin faktycznego działania i kodowania agentów. Kalendarzowo rozciągnęło się to na jakieś dwa tygodnie, bo wysyłałem prompt, pracowałem nad innymi filmami, a czasem po prostu siedziałem bezczynnie. Ale realna praca to około 5 dni.
W ciągu tych 5 dni zebrało się łącznie 334 godziny działania różnych agentów. Pracowały równolegle, więc to suma, a nie czas zegarowy — 334 godziny Codeksu ostro dojeżdżającego moje konto.
W całym procesie powstało tylko 76 agentów — mowa o unikalnych subagentach. Podejrzewam, że system mocno je recyklingował: agent przychodził, brał zadanie, coś robił, raportował i czekał. Ciekawiło mnie natomiast, ile razy faktycznie delegowano pracę do subagentów — tego było znacznie więcej, powiedziałbym co najmniej 300, bo zrobiłem mnóstwo pętli testowych i weryfikacyjnych, gdzie co najmniej 50 agentów szło rojem klikać po aplikacji i próbować ją rozwalić.
Teraz koszty. Tokenów wejściowych: 32 103 178 736. Tokenów wyjściowych: 47 milionów — szczerze spodziewałem się większej liczby. Przeliczone na dolary: to był projekt za 15 tysięcy dolarów.
Korzystałem z planu Codex za 200 dolarów miesięcznie, więc na szczęście nie zapłaciłem 14–15 tysięcy. To ciekawe, bo mniej więcej 14 tysięcy dolarów to tyle, ile wyciska się z maksymalnie wykorzystanego planu Codex za 200 dolarów miesięcznie. W Claude Code przy tym samym planie za 200 dolarów to około 8 tysięcy dolarów inferencji. Czyli z Codeksu wyciągniesz przy maksymalnym wykorzystaniu jakieś 6 tysięcy dolarów więcej. A ja ten plan zdecydowanie wymaksowałem — wszedłem nawet w obszar dodatkowych kredytów. Z całego kosztu jakieś 150 dolarów wyłożyłem z własnej kieszeni, resztę pokrył abonament.
(Informacja dodatkowa: te kwoty to wycena zużytej inferencji według cennika API, a nie realny wydatek autora — abonament ryczałtowy pokrył niemal całość.)
Czy to naprawdę jest „darmowe na zawsze”
Mam nadzieję, że te statystyki są dla was ciekawe. Ale jak mówiłem: to nie byłoby całkowicie darmowe na zawsze, gdybym chciał tego faktycznie używać. Musiałbym co miesiąc wysłać kilka promptów, wprowadzić kilka usprawnień, w miarę jak wychodzą nowe błędy. Mimo to prawdopodobnie i tak wypada lepiej niż płacenie abonamentu — pod warunkiem, że jesteś gotów poświęcić trochę uwagi na utrzymywanie tego od zaplecza.
Jeśli chcecie zobaczyć cały ten proces przy podłączaniu poświadczeń i integracji, zajrzyjcie do filmu, w którym robiłem całodniowy budowanie na żywo innego produktu SaaS.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Klonowanie znanego SaaS-u na własny użytek jest już realne
Na czym polega: Rdzeń funkcjonalności Calendly — synchronizacja kalendarza, typy wydarzeń, publiczny link rezerwacyjny, płatności — udało się odtworzyć w tydzień, przy pięciu promptach do agenta kodującego i kilku ręcznych poprawkach.
Jak stosować: Wybieraj narzędzia o wąskim, dobrze zrozumianym zakresie i stabilnych integracjach (kalendarz, płatności). Im bardziej funkcja jest „standardowa”, tym lepiej agent ją odtworzy, bo istnieje mnóstwo materiału źródłowego na jej temat.
Na co uważać: Odtworzony został rdzeń, nie całość — autor sam przyznaje, że brakuje warstwy automatyzacji Calendly. Nie zakładaj parytetu funkcji z komercyjnym produktem tylko dlatego, że główny przepływ działa.
2.Prompt celu z czterema fazami działa lepiej niż seria drobnych poleceń
Na czym polega: Jeden duży prompt narzucił strukturę: badanie → planowanie → budowa → testowanie, przy czym trzy ostatnie fazy zapętliły się w cykl testuj–naprawiaj.
Jak stosować: Pisząc prompt startowy, jawnie nazwij fazy i powiedz, co jest wynikiem każdej z nich. Faza badawcza („sprawdź, co ludzie chwalą i krytykują w X”) daje planowaniu konkretną listę wymagań zamiast domysłów modelu.
Na co uważać: Struktura faz nie zastąpi decyzji produktowych. Agent zaproponuje nazwę, wygląd i zakres, które mogą ci się nie spodobać — u autora projekt sam ochrzcił się „Tempo Cove”. Wymagania krytyczne dla ciebie wpisz do promptu, nie zostawiaj ich modelowi.
3.Rój agentów testujących wyłapuje błędy, ale nie wyłapuje złego UX
Na czym polega: Około 50 agentów przeklikiwało aplikację w pętli i nie zgłosiło żadnego błędu w przepływie rezerwacji. Człowiek od razu zauważył, że pasek postępu wygląda na klikalny, a nie jest.
Jak stosować: Traktuj agentowe testowanie jako zamiennik testów funkcjonalnych, nie badań użyteczności. Po zakończeniu pętli sam przejdź kluczową ścieżkę i notuj momenty, w których twój odruch rozminął się z zachowaniem interfejsu.
Na co uważać: Autor podkreśla, że wyraźnie poprosił agenty o myślenie o doświadczeniu użytkownika — i to nie pomogło. Dodanie do promptu zdania o UX nie jest zabezpieczeniem; potrzebny jest realny przegląd przez człowieka.
4.Wydajność to osobne zadanie, nie efekt uboczny budowy
Na czym polega: Gotowa aplikacja była wyraźnie ociężała — zacinający się kursor, wolne wpisywanie tekstu. Agenty nie zgłosiły tego jako problemu, bo funkcjonalnie wszystko działało.
Jak stosować: Po zakończeniu budowy uruchom osobny prompt celu poświęcony wyłącznie wydajności, z konkretnym progiem liczbowym — autor podał docelowy czas ładowania rzędu 10 milisekund zamiast prosić o „przyspieszenie”.
Na co uważać: Liczbowy cel działa jak kierunek, nie jak gwarancja. Sprawdź efekt sam, ręcznie, na tej ścieżce, która wcześniej mulila.
5.Prawdziwy koszt to inferencja, nie subskrypcja
Na czym polega: Projekt zużył 32 miliardy tokenów wejściowych i 47 milionów wyjściowych, co przelicza się na około 15 tysięcy dolarów wartości inferencji. Autor zapłacił 200 dolarów abonamentu plus jakieś 150 dolarów dopłaty.
Jak stosować: Planując podobne przedsięwzięcie, licz koszt w tokenach i sprawdź, czy twój plan abonamentowy udźwignie takie obciążenie. Przy pracy rozliczanej per token ten sam projekt byłby wydatkiem rzędu kilkunastu tysięcy dolarów.
Na co uważać: Kwota 15 tysięcy to wycena według cennika, nie rachunek autora. Nie cytuj jej jako „ile kosztuje sklonowanie Calendly” — to zależy wprost od modelu rozliczeń, z którego korzystasz.
6.Limity planów za 200 dolarów różnią się między dostawcami
Na czym polega: Według autora maksymalne wykorzystanie planu Codex za 200 dolarów miesięcznie odpowiada mniej więcej 14 tysiącom dolarów inferencji, a analogicznego planu Claude Code — około 8 tysiącom. Sam ten limit wyczerpał i wszedł w dodatkowe kredyty.
Jak stosować: Jeśli twoje obciążenie jest ekstremalne — wielodniowe pętle z rojami subagentów — porównaj realne pułapy planów, a nie tylko cenę miesięczną.
Na co uważać: To pojedyncza obserwacja z jednego projektu, a nie zmierzony benchmark; autor nie pokazuje metodologii. Limity i wyceny dostawców zmieniają się często — zweryfikuj aktualne warunki, zanim podejmiesz decyzję zakupową.
7.Liczba subagentów to nie to samo co liczba delegacji
Na czym polega: W całym projekcie powstało tylko 76 unikalnych subagentów, ale delegacji było — według szacunku autora — co najmniej 300. Agenty były najwyraźniej recyklingowane: brały zadanie, raportowały i czekały na kolejne.
Jak stosować: Czytając statystyki agentowych projektów, patrz na liczbę zadań i sumaryczny czas pracy, a nie na liczbę utworzonych agentów. 334 godziny agentów w 5 dni to miara realnego wysiłku obliczeniowego.
Na co uważać: Autor sam mówi „myślę, że tak to działało” — to jego interpretacja zachowania narzędzia, nie potwierdzona dokumentacja. Nie buduj na tym założeń architektonicznych.
8.Posiadanie warstwy oprogramowania zmienia sposób reagowania na problemy
Na czym polega: Gdy coś w aplikacji uwiera, autor po prostu prosi Codex albo Claude Code o zmianę — narzędzie zna cały kod, więc modyfikacja jest kwestią jednego polecenia, a nie zgłoszenia do supportu.
Jak stosować: Ta korzyść realizuje się dopiero wtedy, gdy agent ma pełny kontekst repozytorium. Trzymaj projekt w jednym miejscu i pracuj nad nim tym samym narzędziem, którym go zbudowałeś.
Na co uważać: „Własność” oznacza też własność wszystkich awarii. Nikt ci nie naprawi integracji z kalendarzem, gdy zmieni się API po stronie Google.
9.„Darmowe na zawsze” oznacza „płacisz uwagą zamiast abonamentem”
Na czym polega: Autor otwarcie koryguje tytuł własnego filmu: realne używanie tego narzędzia wymagałoby kilku promptów i kilku poprawek miesięcznie, w miarę jak wychodzą nowe błędy.
Jak stosować: Zanim zrezygnujesz z subskrypcji na rzecz własnego klona, oszacuj miesięczny nakład utrzymania i porównaj go z ceną abonamentu wyrażoną w twoim czasie. Dla drogich narzędzi zespołowych rachunek częściej wychodzi na plus.
Na co uważać: Koszt utrzymania nie jest stały — rośnie z każdą integracją zewnętrzną. Aplikacja spięta z Google Calendar i Stripe ma dwa niezależne źródła zmian, na które nie masz wpływu.
10.Narzędzie wewnętrzne to nie produkt SaaS
Na czym polega: Autor wyraźnie oddziela zbudowanie czegoś na potrzeby własne lub małego zespołu od zbudowania czegoś, co ma się skalować: dziesiątki tysięcy dolarów miesięcznie na inferencję i bazy, lawina błędów, lawina próśb o funkcje.
Jak stosować: Używaj tego podejścia tam, gdzie liczba użytkowników jest znana i mała, a wymagania niezawodnościowe umiarkowane — narzędzia wewnętrzne, panele operacyjne, prototypy do walidacji pomysłu.
Na co uważać: Kuszące jest potraktowanie działającego demo jako dowodu, że da się z tego zrobić biznes. Autor mówi wprost, że nawet przy wdrożeniu wyłącznie u siebie spodziewa się mnóstwa błędów, za które ktoś z zespołu będzie musiał wziąć odpowiedzialność.