Alternatywa dla ShipFast dla tych, którzy zamierzają być tu jeszcze w drugim roku

Ostatnia aktualizacja: 15 sierpnia 2026. Każde twierdzenie o ShipFast pochodzi z jego publicznej strony i dokumentacji i ma link na dole. Każda liczba o tej bazie kodu pochodzi z jej własnego zestawu testów, a dokumentacja jest publiczna, więc możesz to sprawdzić.

Liczba, którą ShipFast publikuje, i ta, której nie publikuje

ShipFast robi coś, czego większość boilerplate'ów unika: pokazuje swoją arytmetykę. Strona główna wypunktowuje pracę, którą usuwa, i sumuje ją. Maile, trzy godziny. Landing page, sześć. Webhooki Stripe, cztery. Tagi SEO, dwie. Google OAuth, jedna. DNS, trzy. Chronione trasy API, dwie. „22+ hours of headaches."

Ta liczba jest uczciwa, a rynek się z nią zgadza. 8393 twórców zapłaciło za ten produkt. Jedna z opinii na stronie podaje osobisty wynik: „15+ hrs." Nie mam z tym żadnego sporu. Jeśli Twoim celem jest mieć landing, logowanie i działający checkout na żywo przed poniedziałkiem, ShipFast jest właściwym zakupem i ten artykuł nie będzie Cię od niego odwodził.

Druga liczba to ta, której nie publikuje żaden starter, bo trudniej ją rozpisać i jest znacznie większa:

Ile godzin dzieli Twój start od drugiej płacącej grupy klientów?

Nie od pustego folderu do wdrożenia. Od wdrożenia do firmy. To ten odcinek, na którym pierwszy zespół prosi o stanowiska, dział finansowy pierwszego klienta prosi o fakturę z nazwą swojej spółki, odkrywasz, że „usuń konto" musi kaskadować przez dziewięć tabel, a ktoś pyta, czy aplikacji da się używać po niemiecku.

Godzina 22 to pytanie o boilerplate. Godzina 300 to pytanie o architekturę, a te dwie rzeczy mają ze sobą niewiele wspólnego.

W skrócie

Wszystko w kolumnie ShipFast pochodzi z jego strony głównej i spisu treści dokumentacji. „Brak sekcji w dokumentacji" znaczy dokładnie tyle i nic więcej: publiczne docsy dzielą się na Tutorials, Features, Components, Security, Deployment i Extras, a żaden z tych działów nie zawiera strony o danym temacie.

Co ShipFast robi dobrze, bez zastrzeżeń

Trzy rzeczy, i nie są małe.

Oferta jest niezwykle uczciwa. Większość boilerplate'ów sprzedaje rezultat. ShipFast sprzedaje odcinek czasu, podaje ten odcinek i pozwala Ci sprawdzić, czy jest wart ceny. To lepszy kawałek pozycjonowania niż prawie cokolwiek innego w tej kategorii i dlatego ta liczba jest tak często cytowana.

Biblioteka komponentów jest naprawdę użyteczna. Nagłówki, hero, opinie, cenniki, sekcje FAQ, modale. Jeśli kiedykolwiek spędziłeś sobotę na doprowadzaniu tabeli cennika do porządku, wiesz, że warstwa marketingowa to realna praca, którą założyciele systematycznie niedoceniają.

Zakres jest zdyscyplinowany. ShipFast nie udaje platformy korporacyjnej. Celuje w ludzi szybko weryfikujących pomysły, jego twórca mówi to wprost, a produkt jest z tym celem spójny. Narzędzie, które wie, czym nie jest, zdarza się rzadziej, niż powinno.

Jeśli uruchamiasz płatny newsletter, jednoosobową nakładkę na AI, katalog albo cokolwiek, gdzie klientem jest jedna osoba z jedną kartą, przestań czytać. Kup ShipFast. Będziesz na żywo szybciej, a ten artykuł nie jest dla Ciebie.

Cztery decyzje i koszt każdej w godzinie 300

Reszta jest dla tego drugiego czytelnika: tego, który buduje coś, za co zapłaci firma, z więcej niż jednym stanowiskiem, i który zamierza to utrzymywać, gdy będzie miało klientów.

1. Baza dokumentowa pod produktem relacyjnym

Stack ShipFast jest podany na stronie głównej jako „Mongo + Mailgun + Stripe + NextJS + Tailwind + NextAuth = ShipFast", z Supabase jako alternatywą.

Obiekty, na których SaaS wystawia rachunki, są relacyjne i nie przypadkiem. Użytkownik należy do organizacji. Organizacja ma subskrypcję. Subskrypcja produkuje faktury. Faktura ma pozycje odwołujące się do ceny odwołującej się do produktu. Każda strzałka w tym zdaniu to klucz obcy.

W Postgresie te strzałki są ograniczeniami. Baza odmawia osierocenia faktury. Kaskada przy usuwaniu konta jest właściwością schematu, a nie ścieżką kodu, o której ktoś, mam nadzieję, pamiętał. Raport łączący subskrypcje z organizacjami i stanowiskami to jedno zapytanie.

W bazie dokumentowej każda z tych strzałek staje się kodem aplikacji. Złączenie to druga podróż do bazy. Gwarancja integralności to konwencja. Nic z tego nie jest problemem w godzinie 22, gdy masz cztery dokumenty i jednego użytkownika. To rodzaj problemu, który przychodzi po cichu w godzinie 300, gdy zgłoszenie mówi, że anulowana organizacja wciąż jest obciążana, a znalezienie przyczyny zajmuje dwa dni.

Jest jeszcze jeden szczegół charakterystyczny dla tej dekady. Agenty piszą znacznie lepszy kod relacyjny niż dokumentowy, bo schemat jest typem: typowany query builder nad zadeklarowanym schematem Postgresa zamienia błędną kolumnę w błąd kompilacji. Opisaliśmy ten mechanizm w tekście o wyborze stacku SaaS pod agenty AI i tutaj działa on ze zdwojoną siłą. Zły kształt w bazie dokumentowej kompiluje się, wdraża i poprawnie działa na demie.

2. NextAuth i to, co dzieje się przy trzecim stanowisku

NextAuth rozwiązuje „pozwól człowiekowi zalogować się przez Google" i robi to dobrze. Funkcje, których potrzebuje produkt biznesowy, leżą tuż za tym: organizacje z zaproszeniami, role bramkujące konkretne akcje, dwuskładnikowe uwierzytelnianie wymuszone polityką, a nie oferowane jako opcja, impersonacja dla wsparcia, unieważnianie sesji, gdy ktoś odchodzi z firmy, i ślad audytowy dla wszystkiego powyżej.

Żadna z tych rzeczy nie jest egzotyczna. Każda z nich jest w pierwszej ankiecie bezpieczeństwa, którą przyśle Ci pierwszy klient biznesowy. I każda, dodana późno, dotyka modelu sesji, a to znaczy, że dotyka wszystkiego, co tę sesję czyta.

Alternatywą nie jest tyle inna biblioteka, ile inne założenie początkowe: że kod uwierzytelniania leży w Twoim repozytorium, w czytelnych źródłach, z modelem organizacji i ról już obecnym w schemacie, niezależnie od tego, czy go włączysz. To znaczy „Better Auth w Twoim repozytorium" z tabeli powyżej. To także powód, dla którego w drugim roku nie masz w kosztach pozycji naliczanej od aktywnego użytkownika miesięcznie.

3. Dwa repozytoria i system typów jako preferencja

ShipFast wydaje wersję w JavaScripcie i wersję w TypeScripcie. To broniona decyzja produktowa. To także wypowiedź strukturalna, a brzmi ona: system typów jest opcją dystrybucji, a nie ograniczeniem.

Porównaj z tym, jak wygląda ścisłość, gdy nie jest opcjonalna. Konfiguracja TypeScriptu w tej bazie kodu to nie „strict: true" i nic więcej:

{
  "strict": true,
  "exactOptionalPropertyTypes": true,
  "noUncheckedIndexedAccess": true,
  "noPropertyAccessFromIndexSignature": true,
  "noImplicitReturns": true,
  "noFallthroughCasesInSwitch": true,
  "noUnusedLocals": true,
  "noUnusedParameters": true,
  "verbatimModuleSyntax": true,
}

Samo noUncheckedIndexedAccess zmienia charakter bazy kodu: array[0] ma typ T | undefined, więc błąd „przecież tam oczywiście coś jest" staje się błędem kompilacji, a nie telefonem o trzeciej w nocy. exactOptionalPropertyTypes oznacza, że jawne undefined to nie to samo co brak klucza, a to dokładnie ta różnica, która produkuje ciche gubienie danych w obsłudze aktualizacji.

Do tego typescript/no-explicit-any jest błędem, a nie ostrzeżeniem, a linter działa z denyWarnings: true. Nie ma furtki na any i nie ma ostrzeżenia, które można nauczyć się ignorować, bo ostrzeżenie wywala build.

Nie chodzi o to, że użytkownicy ShipFast piszą zły kod. Chodzi o to, że baza kodu, w której ścisłość jest wyborem per projekt, po odpowiednio długim czasie i odpowiedniej liczbie współpracowników będzie gdzieś zawierać ten słabszy wybór. I nie dowiesz się gdzie, dopóki nie zacznie to mieć znaczenia.

4. Sekcje, których dokumentacja nie ma

To najbardziej użyteczna rzecz, jaką możesz zrobić, oceniając dowolny starter, i zajmuje cztery minuty: otwórz spis treści dokumentacji zamiast strony głównej.

W ShipFast to Tutorials, Features, Components, Security, Deployment, Extras. W Features: SEO, baza danych, maile, płatności, OAuth, magic linki, wsparcie, obsługa błędów, analityka. W Security: rate limiting, limity wysyłki, nagłówki bezpieczeństwa, walidacja schematów. To dobrze zorganizowana dokumentacja dla produktu, którym ShipFast jest.

Czego tam nie ma: testów, multi-tenancy, organizacji, ról i uprawnień, panelu administracyjnego, internacjonalizacji.

Brak strony w dokumentacji nie jest dowodem, że funkcji nie ma. Jest jednak wiarygodnym wskaźnikiem tego, czy funkcja jest wspieraną częścią produktu, czy czymś, co masz zbudować sam. A każda z tych sześciu to tydzień pracy przychodzący w najgorszym możliwym momencie, czyli wtedy, gdy masz już klientów zależnych od rzeczy, którą właśnie masz przebudować.

Godzina 300: rozpisana reszta

Oto druga arytmetyka, w tym samym duchu co pierwsza. To ostrożne szacunki dla kompetentnego programisty budującego każdą pozycję na poziomie, który mógłby pokazać płacącej firmie, i nie obejmują czasu spędzonego na decydowaniu, jak to zrobić.

Przy 150 dolarach za godzinę dolny koniec tego zakresu to 33 000 dolarów. Górny przekracza 53 000. Wobec tego różnica między boilerplate'em za 199 a tym za 249 nie jest liczbą wartą sekundy zastanowienia.

I godziny są tanią częścią. Droga część jest taka, że cztery z tych ośmiu pozycji, czyli izolacja najemców, uprawnienia, idempotencja webhooków i unieważnianie sesji, mają jedną wspólną cechę: zła implementacja przechodzi recenzję i poprawnie działa na demie. Psuje się później, po cichu, na produkcji, na cudzych danych. To nie jest kategoria błędów, którą naprawia się większą liczbą godzin. To kategoria, której unika się, startując z fundamentu, gdzie ktoś ten błąd już popełnił i naprawił.

Różnica, która nie jest funkcją

Tabelki funkcji to najsłabsza forma porównania, bo każdy może dodać wiersz. Oto różnica, której konkurent nie dopisze do tabelki w przyszłym tygodniu, bo jest właściwością tego, jak kod trzyma się razem.

W tej bazie kodu architektura jest wykonywalna. Nie udokumentowana. Wykonywana, przez linter, przy każdym commicie.

// vite.config.ts, skrócone
{
  files: ["src/modules/*/domain/**/*.{ts,tsx}"],
  rules: {
    "no-restricted-imports": ["error", { patterns: [{
      group: ["react", "react/**", "next", "next/**", "drizzle-orm", "drizzle-orm/**",
              "~/src/app/**", "~/src/presentation/**", "~/src/platform/**",
              "~/src/integrations/**", "~/src/modules/*/infrastructure/**",
              "~/src/modules/*/application/**"],
      message: "Domain may only import shared-kernel domain and same-context domain code.",
    }] }],
  },
}

Takich reguł są trzy. Kod domenowy nie może importować Reacta, Nexta, ORM-a, infrastruktury ani warstwy aplikacji. Warstwa aplikacji nie może importować infrastruktury. Prezentacja nie może importować Drizzle ani sięgać do infrastruktury modułu i musi wywołać przypadek użycia.

Konsekwencję warto powiedzieć wprost. Nie możesz przypadkiem wstawić zapytania do bazy w komponencie Reacta. Nie „nie powinieneś". Nie możesz: build się wywala z komunikatem, który mówi dlaczego. Nowy współpracownik uczy się architektury w czasie potrzebnym na przeczytanie jednego błędu. Tak samo agent, co jest dziś w zasadzie tym samym zdaniem.

Każdy starter ma diagram architektury w readme. Bardzo niewiele ma taki, z którym zgadza się kompilator. Po pół roku to jest różnica między bazą kodu, która wciąż ma zaprojektowany kształt, a taką, która po cichu stała się folderem z plikami.

Kto powinien kupić ShipFast

Bez owijania, bo porównanie, w którym konkurent wypada bezwartościowo, to porównanie, w które nikt nie wierzy.

Kup ShipFast, jeśli weryfikujesz pomysł, a uczciwie oczekiwana żywotność kodu to mniej niż pół roku. Kup, jeśli Twoim klientem jest osoba, a nie firma. Kup, jeśli robiłeś już ten stack i wiesz dokładnie, które części wymienisz. Kup, jeśli czas do działającego checkoutu jest jedyną metryką, która liczy się w tym miesiącu, bo w tej metryce ShipFast jest doskonały i ma 8393 osoby, które to potwierdzają.

Stojąca za nim strategia jest spójna: wypuszczaj wiele rzeczy szybko, zostaw tę, która zadziała, resztę porzuć. Jeśli to jest Twoja strategia, kup narzędzie zbudowane pod nią.

Kto powinien kupić to zamiast

Kup to, jeśli budujesz jedną rzecz i zamierzasz budować ją jeszcze za dwa lata. Jeśli Twoim klientem jest firma, co znaczy stanowiska, faktury, role i ankietę bezpieczeństwa. Jeśli wolisz mieć auth na własność niż wynajmować je od aktywnego użytkownika. Jeśli kiedykolwiek odziedziczyłeś bazę kodu bez testów i pamiętasz, jak to było. Jeśli chcesz architektury egzekwowanej, a nie opisanej.

I kup, jeśli przeszedłeś już pierwszą wersję tej historii raz, bo to najczęstszy powód, dla którego ludzie tu trafiają.

Przeniesienie projektu z ShipFast

Uczciwa droga to nie migracja i każdy, kto mówi inaczej, coś sprzedaje.

Cena, uczciwie

ShipFast kosztuje 199 dolarów za Starter i 249 za All-in w chwili pisania, oba przecenione z wyższych cen katalogowych, oba jednorazowo, oba na nieograniczone projekty.

SaaSy Land kosztuje 249 dolarów jednorazowo. Nieograniczone projekty, licencja komercyjna, dożywotnie aktualizacje rdzenia, bez opłat za stanowisko i bez opłat od aktywnego użytkownika.

Te ceny są na tyle blisko siebie, że nie powinny decydować. Decydować powinno to, który z dwóch pozostałych rachunków wolisz zapłacić: 220 do 355 godzin z tabeli powyżej czy pięćdziesiąt dolarów.

Powiązane teksty

Najczęstsze pytania

Źródła

• Strona główna ShipFast, dla cen, linii stacku, rozpisu 22 godzin i liczby klientów
• Dokumentacja ShipFast, dla struktury dokumentacji i opcji repozytoriów JavaScript i TypeScript
• Dokumentacja SaaSy Land, dla konfiguracji, listy modułów i bramki testowej
• Pliki tsconfig.json i vite.config.ts w tym repozytorium, dla cytowanych wyżej flag kompilatora i reguł lintera

Napisał Piotr J. Borowiecki, który buduje SaaSy Land. Dane o ShipFast odczytano z jego publicznych stron 15 sierpnia 2026 i mogły się od tego czasu zmienić; linki powyżej prowadzą do źródła, a nie do zrzutu ekranu.