Supastarter kontra SaaSy Land: usuwać to, czego nie potrzebujesz, czy nigdy tego nie generować

Ostatnia aktualizacja: 15 sierpnia 2026. Każde twierdzenie o Supastarter 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.

Zacznijmy od części, która nie jest krytyką

Jeśli masz Supastarter na krótkiej liście, masz gust. To najpoważniejszy płatny konkurent w tej kategorii i nie ma nic wspólnego z weekendowymi szablonami dominującymi wyniki wyszukiwania. 1460 programistów go kupiło. Jest porządnie utrzymywany od lat. Jego autor jest inżynierem, a nie marketerem, co widać w kodzie i w dokumentacji.

Cztery rzeczy, których większość tej kategorii nie robi w ogóle:

Prawdziwe monorepo, podzielone na cztery. apps/marketing, apps/saas, apps/docs i apps/mail-preview, każda z własnym package.json, next.config.ts, tsconfig.json, layoutami i konfiguracją Playwrighta. Jeśli chcesz, żeby strona marketingowa wdrażała się niezależnie od aplikacji, to jest już zrobione i jest to naprawdę dobry domyślny wybór dla firmy, która kiedyś będzie mieć dział marketingu.

Opcje płatności, których nikt inny nie dodaje. Stripe, Lemon Squeezy, Polar, Creem i Dodo Payments. Zwłaszcza Creem i Dodo to merchant of record, których europejski założyciel może chcieć konkretnie ze względu na VAT, a znalezienie ich wspieranych z pudełka jest rzadkością.

Auth, które jest naprawdę skończone. Hasła, passkeys, magic linki, dwuskładnikowe, OAuth, przypomnienie i reset hasła, role i uprawnienia, super admin i impersonacja. Ta lista nie jest marketingiem. Zwłaszcza impersonacja to funkcja, o którą każdy zespół wsparcia prosi czterdziestego dnia i której nikt nie buduje pierwszego.

Wybór ORM-a. Prisma albo Drizzle, Twoja decyzja. Wielu kupujących ma tu silną preferencję, a bycie zmuszonym do jednego jest realną irytacją.

Ktokolwiek mówi Ci, że Supastarter to rozdmuchany weekendowy kod, go nie czytał. Reszta tego artykułu to porównanie dwóch wiarygodnych opcji, a nie demontaż.

W skrócie

Decyzja, która zapada przed pierwszą komendą

Każdy starter odpowiada na jedno pytanie, zanim odpowie na jakiekolwiek inne: co dostaje kupujący?

Odpowiedzi są dokładnie dwie i produkują zupełnie różne dwa lata.

Odpowiedź pierwsza: wszystko, a Ty usuwasz. Klonujesz repozytorium zawierające każdą funkcję, którą produkt obsługuje. Organizacje, wszystkie pięć bramek płatności, aplikację docs, aplikację podglądu maili, moduł AI. Potem usuwasz to, czego nie potrzebujesz. Udokumentowany start Supastarter to npx supastarter new my-awesome-project, opisane w dokumentacji jako klonowanie, konfigurowanie i instalowanie.

Odpowiedź druga: tylko odpowiedzi. Dostajesz pytania. Generator pisze moduły odpowiadające Twoim odpowiedziom i nic poza tym. Projekt jednonajemcowy nie ma nigdzie kodu organizacji. Projekt bez płatności nie ma obsługi webhooka Stripe, którą trzeba by przeczytać i pominąć. To właśnie robi konfigurator CLI na naszej stronie głównej, na żywo, na Twoich oczach: dwanaście pytań, cztery opcjonalne funkcje i komenda, która zmienia się wraz z odpowiedziami.

Obie są uzasadnione. Pierwsza daje Ci kompletną implementację referencyjną, którą możesz studiować, a są dni, gdy posiadanie kodu, którego nie potrzebujesz, jest lepsze niż jego brak. Druga daje mniejsze repozytorium, co znaczy więcej, niż brzmi.

Dlaczego znaczy więcej, niż brzmi.

Nieużywany kod nie jest darmowy. Czyta go każdy nowy programista. Przeszukuje go każdy grep. Pojawia się w każdym „znajdź użycia". Przechodzi przez niego bundler. Ląduje w oknie kontekstowym każdego agenta, którego wskażesz na repozytorium, a to jest dziś realny budżet, a nie metafora. I co najważniejsze, jest to kod, za który odpowiadasz, a którego nie napisałeś, czyli najgorsza możliwa kombinacja.

Najjaśniejsza wersja tego argumentu: jeśli generujesz projekt jednonajemcowy, jak bardzo jesteś pewien, że gdzieś nie działa jeszcze zapytanie ograniczone do organizacji? Przy drugiej odpowiedzi pytanie jest bez sensu, bo ten kod nie istnieje.

Dlaczego merge z upstreamu robi się trudniejszy, nie łatwiejszy

To jest ta część porównania, którą chciałbym mieć wyjaśnioną, zanim cokolwiek kupię, a mówi się o niej rzadko.

Dokumentacja Supastarter jest tu jednoznaczna i, co należy mu przyznać, uczciwa co do mechanizmu. Ustawiasz repozytorium Supastarter jako upstream swojego projektu, „so you can pull in updates in the future", przez git remote add upstream https://github.com/supastarter/supastarter-nextjs.git. Fetch, merge, rozwiąż konflikty.

Pierwszego dnia działa to wspaniale. Nie zmieniłeś prawie nic, więc merge jest fast-forward.

Rozważ osiemnasty miesiąc. Przepisałeś dashboard, przebudowałeś UI płatności, zmieniłeś schemat użytkownika i usunąłeś dwie aplikacje, których nigdy nie użyłeś. Teraz przychodzi nowa wersja.

Prawdziwe są teraz trzy rzeczy, i są strukturalne, a nie czyjąś winą:

Powierzchnia konfliktu to przecięcie ich zmian z Twoimi i tylko rośnie. Każdy plik, który tknąłeś, to plik, który może wejść w konflikt. Twoja produktywność jako budującego jest dokładnie tym, co utrudnia aktualizację, a to zachęta, której nikt nie chce.

Usunięcia nie są pamiętane. Usunąłeś apps/docs, bo używasz hostowanego produktu do dokumentacji. Upstream wciąż to ma. Każdy kolejny merge proponuje to znowu. Podejmujesz tę samą decyzję w nieskończoność, aż pewnego dnia przypadkiem ją zaakceptujesz podczas dużego merge i odkryjesz aplikację docs na produkcji.

Merge jest wszystko albo nic na poziomie commita. Aktualizacja zawiera poprawkę bezpieczeństwa w auth i przeprojektowanie ekranu ustawień, który już przeprojektowałeś. Chcesz pierwszego, nie chcesz drugiego, a git Ci tego nie rozdzieli.

Alternatywa nie jest magią i chcę być w tym precyzyjny. Generator nie eliminuje pracy przy aktualizacjach. Zmienia jej kształt: ponieważ narzędzie zapisało, które moduły wygenerowałeś, aktualizację można wyrazić jako diff dokładnie dla tych modułów, wobec bazy odpowiadającej temu, co faktycznie wziąłeś. Możesz wygenerować czysty projekt z tymi samymi odpowiedziami i porównać go ze swoim. To czytelna operacja. Merge osiemnastomiesięcznego forka czteroaplikacyjnego monorepo nie jest.

Testy E2E i bramka pokrycia to dwa różne twierdzenia

Dokumentacja Supastarter wymienia testy E2E w Playwright. To realne, to więcej, niż oferuje większość konkurencji, i nie zamierzam udawać inaczej.

To także inne twierdzenie niż to, które stawia ta baza kodu, a różnicę warto zrozumieć, bo obie rzeczy trafiają do szufladki „ma testy".

Zestaw E2E dowodzi, że ścieżki, dla których napisałeś testy, działają dziś. Przeprowadza przeglądarkę przez rejestrację, checkout i kilka przepływów. Świetnie łapie katastrofy i jest bezużyteczny wobec szczegółów.

Bramka pokrycia w ogóle nie pozwala zmergować nieprzetestowanej gałęzi. Oto faktyczna konfiguracja z vite.config.ts tego repozytorium:

coverage: {
  thresholds: {
    branches: 100,
    functions: 100,
    lines: 100,
    statements: 100,
  },
}

Cztery liczby, wszystkie równe 100, wszystkie egzekwowane. Dziś ta bramka działa na 141 plikach testowych i 472 testach. Warstwa tras src/app/** i generowany kod integracji są wykluczone, co jest zapisane w konfiguracji, a nie ukryte, bo bramkowanie kleju frameworkowego produkuje testy, które niczego nie sprawdzają.

Praktyczna różnica ujawnia się w konkretnym miejscu: w gałęzi błędu. Twoja obsługa webhooka ma ścieżkę dla podpisu, który się nie zgadza. Twój przepływ zaproszeń ma ścieżkę dla tokenu, który wygasł. Twoje sprawdzenie uprawnień ma ścieżkę zwracającą fałsz. Zestaw E2E prawie nigdy ich nie wykonuje, bo przygotowanie błędnego podpisu w teście przeglądarkowym jest żmudne i wszyscy to pomijają. Bramka pokrycia gałęzi na 100 nie pozwoli Ci ich zmergować bez testu.

A te gałęzie są dokładnie tam, gdzie psują się produkty SaaS, bo nikt nie przechodzi ich ręcznie przed wydaniem.

Cztery aplikacje, których możesz nie chcieć

Czteroaplikacyjne monorepo jest wyżej wymienione jako zaleta Supastarter i dla właściwego kupującego nią jest. Warto jednak nazwać koszt, bo „monorepo" to słowo, które ludzie przyjmują jako automatycznie dobre.

Cztery aplikacje to cztery pliki package.json, cztery tsconfig.json, cztery konfiguracje Nexta, cztery pipeline'y build i cztery zestawy aktualizacji zależności. Jeśli jesteś jedną osobą budującą jeden produkt, obsługujesz teraz strukturę zespołu platformowego, mając czas jednoosobowego założyciela.

Alternatywą nie jest „bez monorepo". Jest nią decydowanie zamiast dziedziczenia. Konfigurator CLI zadaje pytanie o kształt wprost: monolit, osobne API albo mikroserwisy. Wybierz monolit, a dostajesz jeden artefakt i jedno drzewo zależności. Wybierz osobne API, a dostajesz frontend i osobne API. Architektura jest Twoją odpowiedzią na pytanie, a nie właściwością produktu, który kupiłeś.

Architektura, która jest wykonywalna

Oba produkty mają architekturę. Różnica polega na tym, czy wie o niej kompilator.

Granice modułów w tej bazie kodu to reguły lintera, nie dokumentacja:

// 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.",
    }] }],
  },
}

Trzy reguły, w tym samym pliku. 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 i musi przejść przez przypadek użycia.

Efekt: nie możesz przypadkiem wstawić zapytania do bazy w komponencie Reacta. Build się wywala, z komunikatem tłumaczącym dlaczego. To jest różnica między czystą architekturą a bazą kodu, która kiedyś ją miała.

Z każdym miesiącem znaczy to więcej, z powodu niezwiązanego z ludźmi. Agenty uczą się zasad bazy kodu z tego, co się wywala, a nie z readme. Granica wywalająca build to granica, którą agent uszanuje przy drugiej próbie. Granica będąca konwencją to taka, którą będzie uprzejmie i wielokrotnie naruszał. Pisaliśmy o tym w tekście o gotowości repozytorium pod agenty AI.

Ile faktycznie kosztuje każdy z produktów

Plany Supastarter to Solo za 299 dolarów za jedno stanowisko, Startup za 799 dolarów za maksymalnie pięć stanowisk z konsultacją i priorytetowym wsparciem oraz Agency za 1499 dolarów za maksymalnie dziesięć stanowisk, gotowe pod white label, z prywatnym kanałem na Discordzie.

SaaSy Land to 249 dolarów za bazę kodu, 399 z wideokursem i 899 za plan agencyjny. Wszystko jednorazowo. Wszystko na nieograniczone projekty. Bez liczenia stanowisk w żadnym z planów.

Żeby być uczciwym: plany Startup i Agency zawierają realne rzeczy poza stanowiskami. Godzinna konsultacja z autorem ma wartość. Priorytetowe wsparcie ma wartość. Dostęp do założyciela na prywatnym Discordzie ma wartość. Jeśli to jest to, czego chcesz, cena jest broniona i powinieneś kupić to, czego chcesz.

Ale jeśli tym, czego chcesz, jest kod źródłowy, liczba stanowisk jest decyzją licencyjną, a nie produktową, i jest to rodzaj decyzji, który zaczyna irytować dokładnie wtedy, gdy Twojej firmie idzie dobrze.

Kto powinien kupić Supastarter

Kup Supastarter, jeśli chcesz czteroaplikacyjne monorepo z pudełka i i tak byś je zbudował. Jeśli potrzebujesz konkretnie Creem albo Dodo Payments, bo prawie nikt inny ich nie wspiera. Jeśli cenisz kompletną implementację referencyjną, którą możesz przeczytać i sam przyciąć, bardziej niż generator decydujący za Ciebie. Jeśli godzinna rozmowa z autorem jest dla Ciebie warta kilkuset dolarów, a dla części kupujących jasno jest. Jeśli jesteś na Prismie i zamierzasz przy niej zostać.

To dobry produkt z realnymi klientami i nie przyniesie Ci wstydu.

Kto powinien kupić to zamiast

Kup to, jeśli chcesz repozytorium zawierające wyłącznie kod, o który poprosiłeś. Jeśli bramka pokrycia 100% jest czymś, co faktycznie utrzymasz, bo dla kogoś, kto wyłączy ją w drugim tygodniu, jest bezwartościowa. Jeśli architektura jest dla Ciebie na tyle ważna, że chcesz mieć ją egzekwowaną przez linter. Jeśli Twój zespół jest większy niż jedna osoba i wolisz nie liczyć stanowisk. Jeśli możesz nie chcieć Next.js, bo TanStack Start i React Router są tu opcjami. Jeśli chcesz sklep z przykładowymi produktami, kurs w subskrypcji, kreator stron albo wizualny edytor wpisów, które są tu opcjonalnymi dodatkami, a tam nie są oferowane.

I kup to, jeśli sporą część dnia pracujesz z agentami, bo wszystko powyżej o egzekwowanych granicach i mniejszym repozytorium jest warte więcej dla agenta niż dla Ciebie.

Powiązane teksty

Najczęstsze pytania

Źródła

• Strona główna Supastarter, dla planów cenowych, liczby stanowisk, listy funkcji i liczby klientów
• Dokumentacja Supastarter, dla struktury monorepo i czterech aplikacji
• Dokumentacja instalacji Supastarter, dla komendy CLI i modelu aktualizacji przez upstream
• Dokumentacja SaaSy Land i konfigurator, dla listy modułów i pytań generatora
• Plik vite.config.ts w tym repozytorium, dla progów pokrycia i cytowanych reguł lintera

Napisał Piotr J. Borowiecki, który buduje SaaSy Land. Dane o Supastarter odczytano z jego publicznych stron 15 sierpnia 2026 i mogły się od tego czasu zmienić; linki prowadzą do źródła, a nie do zrzutu ekranu. Jeśli cokolwiek tutaj jest nieaktualne albo błędne, napisz, a poprawię.