Jak spalić milion złotych na aplikacji, której nie zbudujesz

Jest piątek, połowa grudnia. Marek (38, ex-McKinsey, technologię zna na poziomie Excela) odpisuje na czwarty z rzędu mail z banku. Subject: „Saldo poniżej zera. Limit przekroczony."

Czternaście miesięcy temu zamknął rundę pre-seed: 1 milion złotych za 18% udziałów. Funda od polskiego anioła z portfolio w fintechu, który widział pomysł, polubił trakcję early-adopters w community Marka, ale nie miał czasu mentorować technicznie. Plan: pierwsza wersja produktu na rynek w 6 miesięcy, walidacja, runda A w 12.

Aplikacja nigdy nie wyszła. W styczniu zespół (sześć osób, mid-tier dewski team plus PM) złożył zbiorówkę. Środowiska AWS-owe zaczęły się walić, bo cztery miesiące nie było aktywnego maintenance'u. Co Marek zostawił po sobie w drugim roku? Repozytorium GitHub z 8 400 commitami, połowiczne mobile w React Native, backend microservice'owy w połowie spięty z brokerem MQ, którego nikt nie umiał zdeployować, oraz fakturę z Datadoga na 2 800 zł za zeszły miesiąc.

Marek wrócił do kontraktu w McKinseyu. Anioł zrobił write-off. Pomysł zniknął.

Widziałem ten układ cztery razy w ciągu ostatnich pięciu lat. Marek to ulepiona postać, ale każdy fragment tej historii to czyjeś życie. Robię ten artykuł, żeby pokazać anatomię tej katastrofy, w detalu, z liczbami, bez fluffu, oraz jeden tani sposób, żeby jej uniknąć, gdy następnym razem dostaniesz pre-seed.

Decyzja, która zniszczyła projekt

Marek zatrudnił szóstkę w 8. tygodniu od zamknięcia rundy. Argument: „Im więcej rąk, tym szybciej zbudujemy. Ramp up team, ship MVP, walidacja." Ekosystem polskich startupów chwali ten ruch jako „capital efficiency", recruiter pochwali, anioł kiwnie głową na pierwszej radzie nadzorczej.

Tu jest skład:

Dwanaście miesięcy × 88k = 1 056 000 zł. Cały budżet rundy zjadał payroll, zanim ktokolwiek otworzył Slacka.

Plus narzędzia (Linear, Notion, Slack Pro, Figma, Sentry, Datadog, Vercel, AWS, Stripe sandbox, GitHub Enterprise) = ~3 800 zł/mies extra. Plus agencja UX (15 000 zł na ekrany discovery), prawnicy do umów B2B (8 000 zł), księgowość (1 200 zł/mies), sprzęt (8 laptopów, 7 monitorów = ~80 000 zł).

W ciągu czterech miesięcy budżet był wyczerpany na 65%, zanim padł pierwszy commit produkcyjnego kodu.

Czego brakowało? Seniora, architekta, kogokolwiek, kto siedział z 7+ lat w branży. Decyzje technologiczne zapadały demokratycznie na poniedziałkowych standupach. Każdy mid miał silną opinię, junior milczał, mobile bronił RN, bo to jego jedyny stack, frontend chciał Next.js, bo to trendy. PM moderował głosowanie.

To jest moment, w którym projekt był skończony. Reszta to tylko ile czasu zajmie, żeby ktoś to zauważył.

Pierwsze trzy miesiące fałszywej euforii

Pierwszy sprint planning trwał sześć godzin. Drugi: osiem. Linear był cały zielony. Wireframe'y w Figmie wyglądały spektakularnie, agencja wykonała 47 ekranów discovery w ciągu pięciu tygodni.

Stack technologiczny ustalany przez trzy tygodnie:

• Backend: microservice'y. „Bo jak zrobimy monolit, później będzie ciężko skalować, jak będziemy mieć 100k userów."
• Komunikacja między serwisami: GraphQL Federation + Apache Kafka. „Bo Spotify."
• Bazy danych: PostgreSQL per service + Redis + Elasticsearch (dla search) + ClickHouse (dla analytics). „Każda baza do swojego use case'u, najlepiej."
• Frontend: Next.js App Router + tRPC + Zustand + TanStack Query.
• Mobile: React Native + Redux + WatermelonDB.
• DevOps: Kubernetes na AWS EKS, ArgoCD, Helm charts, Prometheus + Grafana stack, Loki dla logów.
• CI/CD: GitHub Actions + custom runnery na EC2.

Czas od pomysłu do pierwszego deploya działającego feature na staging: dziewięć tygodni. To był ekran logowania.

W tym czasie zespół był „bardzo busy". Migracje, schema designy, rancher konfigurowany trzy razy, bo coś tam się crashowało, GraphQL gateway wymagał napisania 12 resolverów, żeby user mógł się zalogować. Junior backend dostał task na auth flow, przepisał go drugi raz, bo first version używała JWT bez refresh tokens. Trzeci raz, bo ktoś przeczytał, że JWT można podmieniać, i przełączyli się na opaque tokens. Czwarty raz nie było, ale wszyscy stracili wiarę.

To wszystko było busy work, nie postęp. Każda decyzja zapadała ze świadomością „tak robi Spotify / Netflix / Stripe". Nikt nie zauważył, że Spotify zatrudnia 6 800 inżynierów, ma rundy serii G, a ich architektura jest dla problemów, których pre-seed startup nie ma i nigdy mieć nie będzie.

Architektoniczny dług, który zabił projekt

W miesiącu piątym padły pierwsze niezgodności. Trzy serwisy chciały pisać do tabeli users (auth-service, profile-service, billing-service). Każdy miał swoją wersję modelu, każdy zapisywał trochę inaczej, race condition na update'ach. Bug fixy w kółko.

Junior backend popłakał się na sprint review w siódmym tygodniu po dwumiesięcznej walce z auth bugiem (token nie przechodził poprawnie przez gateway przy SSO redirect). Seniora nie było. Midy radzili „dodaj jeszcze jedno middleware". Junior nigdy nie poznał, że problem był w architekturze, nie w jego kodzie.

Mobile? React Native dev wybrał WatermelonDB do offline-first sync. WatermelonDB jest dobre, ale wymaga bardzo specyficznego typu serwera dla wymiany danych. Backend tego nie zaprojektował. Mobile sync nie działał. Po czterech miesiącach mobile dev przepisał klienta na zwykły REST polling z TanStack Query. Spalono 250+ godzin pracy.

Auth flow przepisany trzy razy. Frontend layout przerobiony w połowie projektu, bo ktoś polubił nową wersję shadcn/ui. Schema bazy migrowana 47 razy w pierwszych sześciu miesiącach (większość niekontrolowanych przez pull requesty, devsi pushowali bezpośrednio na main, bo „to staging, nieważne").

W miesiącu dziewiątym doszło do pierwszego deploya na produkcję. Padło cztery razy w pierwszym tygodniu. RDS się zatkał (połączenia nie były poolowane). Kafka nie była partycjonowana (jedna kolejka na wszystko). Sentry zaalarmował 18 000 razy w pierwszej godzinie po włączeniu, zespół wyłączył alerty.

Aplikacja w pseudo-produkcji nie obsługiwała 50 użytkowników bez kładzenia się.

Marek dowiedział się w miesiącu dziesiątym. Do tego momentu zaufał teamowi, że „idziemy do przodu". Linear był zielony. Standupy były pozytywne. Demo na quarterly review wyglądało jak działająca aplikacja (bo było uruchomione na lokalnym laptopie PM-a).

Wyciek wartości: gdzie naprawdę poszedł milion

Po post-mortem (Marek wynajął niezależnego audytora w miesiącu trzynastym, koszt 22 000 zł, sam zwrócił mu się tylko psychologicznie) podział wyglądał tak:

Czyli budżet skończył się w dziewiątym miesiącu. Marek dołożył z prywatnej kieszeni 200 000 zł (kredyt pod mieszkanie), próbował zorganizować bridge round od anioła, anioł odmówił, bo nie widział produktu w produkcji.

Co dostał za 1,4 miliona złotych?

• Zero płacących użytkowników
• MVP w pseudo-produkcji, padający co sześć godzin
• Mobile, którego sync nie działa
• Sześciu kontraktorów, którzy następne dwa lata będą tłumaczyć na rozmowach kwalifikacyjnych „dlaczego startup się rozpadł"
• 47 ekranów Figmy (gotowe do oprawienia w ramki)
• Lekcję, której nikt na MBA nie uczył

Anatomia poznawczego trapu

Marek nie był głupi. Był ex-McKinsey, czytał First Round Capital, słuchał All-In Podcastu. Dlaczego więc?

Trzy błędy poznawcze, które widziałem we wszystkich czterech podobnych przypadkach:

1. „Im więcej osób, tym szybciej." Brooks' Law z 1975: dodawanie ludzi do opóźnionego projektu opóźnia go bardziej. Coordination overhead rośnie kwadratowo. Zespół 6-osobowy ma 15 par komunikacyjnych. Zespół 1-osobowy ma zero. Dla pre-seed MVP coordination overhead je 50–70% czasu zespołu.

2. „Trzeba budować tak, jak budują duzi." False scaling premise. Spotify ma microservice'y, bo ma 575 mln użytkowników i 6 800 inżynierów. Twój pre-seed ma zero użytkowników i sześciu inżynierów. Wybierając stack technologiczny dużych firm, kupujesz ich problemy bez ich zasobów.

3. „Senior będzie drogi, więc zatrudnijmy midów." Senior za 30 000 zł/mies kosztuje cię tyle samo co dwóch midów po 15 000 zł. Ale senior wybiera prawidłowo problem do rozwiązania, midów trzeba prowadzić. W pre-seed problem #1 to decyzyjność, nie velocity. Senior IC zapewnia decyzyjność. Mid bez seniora = chaos po pięknej fasadzie.

Marek wpadł we wszystkie trzy. Każda z tych decyzji z osobna brzmi rozsądnie. Wzięte razem to plan na bankructwo.

Co Marek powinien był zrobić

Plan A: solo senior IC

Zatrudnij jednego niezależnego seniora generalist'a (full-stack: web + mobile + backend + DevOps + CI/CD). Day rate: 1 200–1 800 zł netto, full-time engagement: 25 000–35 000 zł/mies brutto B2B.

12 miesięcy × 30 000 zł = 360 000 zł. Zostało 640 000 zł.

Co kupujesz za pozostałe 640 tysięcy?

• 4–5 miesięcy „expand" budżet po walidacji rynku, zatrudniasz pierwszego specjalistę dopiero, gdy MASZ produkcyjne dane (np. mid frontend ~16 000 zł/mies × 6 mies = 96 000 zł)
• Marketing pierwszych klientów (60–100k)
• Sales calls, content, conference travel (40k)
• Bufor 200k+ na błędy

W sześć miesięcy senior IC dostarcza:

• Working MVP w produkcji (proven stack, jeden senior głowy = jeden architektoniczny model)
• Pierwsze 50–200 płacących użytkowników (validation signal)
• Roadmap rozbudowy bazujący na PRAWDZIWYCH danych, a nie założeniach

Plan B: fractional CTO + execution

Pierwszy etap: fractional CTO na sześć miesięcy advisory (8 000–12 000 zł/mies, 1–2 dni/tydzień). Pomaga ci podjąć decyzje technologiczne, zatrudnić pierwszą osobę, zdefiniować architekturę. Koszt sześciu miesięcy = 60–72k.

Drugi etap: po walidacji konceptu, zatrudnij seniora IC do execution (jak Plan A).

Trzeci etap (post-PMF, miesiąc 10–12): scale team z prawdziwymi sygnałami od użytkowników.

Total z 12 miesięcy: ~430k. Zostaje 570k na operations, marketing, błędy.

Decision framework: kiedy zatrudniać kogo

To nie jest reguła sztywna. Czasem Plan A nie zadziała, bo np. masz hardware komponent, który wymaga dedicated firmware engineera. Czasem Plan B jest lepszy, bo solo founder nie ma technical co-foundera i potrzebuje wsparcia decyzyjnego.

Ale w 70% przypadków pre-seed founderów, których spotykam, „buduj mały zespół" jest błędną odpowiedzią.

Marek wrócił

W marcu 2026 Marek wrócił do mnie. Anioł dał mu drugą szansę po prywatnym dofinansowaniu od rodziny: 250 000 zł, 18 miesięcy runway. Ostatni strzał.

Tym razem zatrudnił jedną osobę, niezależnego seniora, od razu w pierwszym tygodniu po wpłynięciu kasy. Stawka: 30 000 zł/mies B2B. Plan: working MVP w 12 tygodni, 100 płacących userów w 24 tygodnie, decyzja o second hire w 24–26.

W tygodniu jedenastym aplikacja weszła na produkcję. Po jednym deployu, działała. Zero microservice'ów: monolit Next.js + PostgreSQL + Stripe + Resend + Cloudflare R2. Mobile? PWA z service workerem pod offline (bo na pierwszy MVP tylko 8% użytkowników będzie korzystać mobile, jak walidacja pokazała). Stack zajmuje połowę kartki A4.

Po ośmiu miesiącach: 8 000 płacących użytkowników, 24 000 zł MRR. Marek robi rundę pre-A na waluacji 12 milionów złotych. Ten sam zespół w stylu „6 osób od dnia pierwszego" nie wszedłby na ten poziom nawet w 24 miesiące.

Lekcja: w pierwszym roku startupu kapitał ludzki masz nie jako asset, tylko jako koszt. Każda osoba dodatkowa = wzrost coordination overhead, wzrost decyzyjnego paraliżu, dłuższy czas do produktu. Senior IC > zespół, dopóki nie masz powtarzalnego procesu sprzedaży.

Polski startup ecosystem ma chroniczną dietę „trzeba zatrudnić zespół". To kłamstwo. Statystyka rezerwowych krajów (US, UK) pokazuje, że 60% udanych pre-seedów ma 1–2 inżynierów przez pierwsze 9 miesięcy. Twoja seria A nie czeka, aż zatrudnisz szóstkę. Czeka, aż ktoś za to płaci.