KISS or Die: Dlaczego Doświadczeni Inżynierowie Ponoszą Porażkę w Startupach

Mój pierwszy startup zakończył się porażką, podobnie jak kilka sąsiednich startupów. Mieliśmy: 100 tys. dolarów w kredytach GCP, założyciela-inżyniera, który budował systemy w przedsiębiorstwach, oraz strategię wejścia na rynek. I ponieśliśmy porażkę nie dlatego, że zbudowaliśmy to źle, ale dlatego, że zbudowaliśmy to dobrze. To był problem.

Podczas gdy spędzaliśmy czas na zmaganiu się z tym, co wydawało się "nieoptymalnym" stosem technologicznym, straciliśmy najważniejszą rzecz: czas, impet i strategiczną szansę.

Ta historia nie jest o ludziach bez zdrowego rozsądku. Miałem zdrowy rozsądek i wiedzieliśmy, że powinniśmy utrzymywać rzeczy prostymi. Ale kiedy twój model mentalny nie pasuje do sytuacji, cały twój zdrowy rozsądek zostaje zmieciony. Podejmujesz "poprawne" decyzje, które cię zabijają.

To również nie jest historia o złej inżynierii. To o tym, jak dobra inżynieria zabija startupy. Jak doświadczenie, które czyni cię seniorem, staje się twoim największym obciążeniem. Jak "robienie tego dobrze" lub nawet "robienie tego prosto" często oznacza robienie tego źle.

Ten artykuł przedstawia modele mentalne, które pomogą ci podejmować właściwe decyzje i unikać tych błędnych, które ja popełniłem.

:::tip Dla kogo to jest: starsi inżynierowie rozpoczynający lub dołączający do startupów na wczesnym etapie. Jeśli spędziłeś 5+ lat w przedsiębiorstwie lub Big Tech, to jest twoje ostrzeżenie.

:::

\

Model mentalny #1 - "Darmowa" infrastruktura jest najdroższa

100 tys. dolarów w kredytach GCP wydaje się prezentem, ale to pułapka. Popycha cię w kierunku nadmiernej inżynierii, bo "jest już opłacona". Otrzymujesz instancje obliczeniowe, load balancery, rejestry kontenerów i narzędzia korporacyjne, które wymagają korporacyjnej konfiguracji. Czego potrzebujesz? Przycisku "push to deploy".

Oczywiście, możesz zbudować przepływy pracy "deploy from GitHub to VM" na GCP/AWS/Azure. Niektóre produkty są bliskie. Ale wymaga to dodatkowych kroków: konfigurowania Cloud Build, ustawiania ról IAM, pisania skryptów wdrożeniowych, zarządzania sekretami i konfigurowania kontroli stanu. Tracisz czas na budowanie infrastruktury wdrożeniowej przed wdrożeniem faktycznych produktów.

Tymczasem platformy takie jak Railway lub Fly.io dają ci to, czego startupy naprawdę potrzebują: trwałą maszynę wirtualną z wdrażaniem start-and-go z GitHuba. Tak łatwo, jak to możliwe: wypychasz swój kod i jest wdrażany. Gotowa do użycia maszyna wirtualna ze zmiennymi środowiskowymi, SSL, load balancerami, logami itp. Nie jest "darmowa", ale jest gotowa.

Darmowe kredyty popychają cię w kierunku nadmiernej inżynierii, bo "są już opłacone". Przekonujesz siebie, że oszczędzasz pieniądze, wydając swój najcenniejszy zasób: czas.

\

Model mentalny #2 - "Minimalny" <> "Prosty"

Tradycyjna zasada KISS mówi nam, aby utrzymywać nasze oprogramowanie prostym. Ale w startupach to zły cel. Nie powinieneś utrzymywać OPROGRAMOWANIA prostym; powinieneś utrzymywać ROZWIĄZANIA prostymi.

Prawdziwa prostota powinna być mierzona całkowitym wysiłkiem, a nie złożonością kodu:

Całkowity wysiłek = Początkowa budowa + Utrzymanie + Debugowanie + Dodawanie funkcji + Aktualizacje bezpieczeństwa + Zmiany skalowania

Kiedy budujesz od podstaw, jesteś właścicielem wszystkich tych elementów na zawsze. Kiedy korzystasz z usługi, większość z nich staje się zerowa. "Rozdęta" usługa zewnętrzna jest w rzeczywistości prostym rozwiązaniem, ponieważ minimalizuje całkowity wysiłek.

Mój przykład OAuth

Nasz założyciel-inżynier zdecydował się zbudować OAuth od podstaw zamiast używać "nieznanej biblioteki". Tydzień później złożył PR: czystą implementację OAuth z tokenami JWT, rotacją tokenów odświeżania, zarządzaniem sesjami i kontrolą dostępu opartą na rolach. Bez zależności, bez vendor lock-in, tylko kod, który kontrolowaliśmy.

Nie odrzuciłem PR. I to był błąd. Odrzucenie tygodnia pracy zmiażdżyłoby morale. Ale tworzy to złożoność kodu i stawia go na złych torach. Plus, nieomówienie podejścia wcześniej było naszym prawdziwym błędem. Pozwoliliśmy, aby duma inżynierska podjęła strategiczną decyzję.

Następnie klient potrzebował Microsoft OAuth i Google OAuth. Niestandardowa implementacja oznaczała dni refaktoryzacji, rotacji tokenów odświeżania, przypadków brzegowych, RBA i innych rzeczy. Każde "proste" dodanie wymagało głębokiego zrozumienia naszej niestandardowej autoryzacji. Każda aktualizacja bezpieczeństwa była nasza do wdrożenia. Każde nowe wymaganie było nasze do zakodowania.

Zasady

Klasyczny błąd starszego inżyniera: optymalizacja dla kontroli zamiast dla wyników. W startupach rzeczywistość wymaga całkowitego odwrócenia sposobu myślenia starszych inżynierów:

1. PRZESTAŃ myśleć: "To tylko kilka dni kodowania" \n ZACZNIJ myśleć: "To kilka dni NIE kodowania mojego właściwego produktu"
2. PRZESTAŃ myśleć: "Mogę to zbudować prosto" \n ZACZNIJ myśleć: "Mogę to rozwiązać prosto, nie budując"
3. PRZESTAŃ myśleć: "Usługi zewnętrzne dodają złożoności" \n ZACZNIJ myśleć: "Usługi zewnętrzne pochłaniają złożoność"

\

\

Model mentalny #3 - Wybory komfortowe

Wybraliśmy Angular, ponieważ nasz założyciel-inżynier znał go dogłębnie. Mądra decyzja, prawda? Wykorzystaj swoje mocne strony, dostarczaj jakościowy kod. Framework był w porządku, ALE problemem był jego ekosystem.

Pułapka ekosystemu

Angular jest doskonały i nasz inżynier mógł zbudować z nim wszystko.

Ale "wszystko" zajmowało czas, aby w ogóle zacząć. Konfiguracja wdrażania, uwierzytelniania i podstawowych komponentów UI oznaczała niekończącą się konfigurację przed napisaniem pojedynczej funkcji. Podczas gdy debugowaliśmy motywy Angular Material, konkurenci mogą (i będą) używać Next.js + Vercel i już onboardowali użytkowników.

Porównaj to ze ścieżką Next.js + Vercel: wdrożenie szkieletowej aplikacji za pomocą npx create-next-app pierwszego dnia, dodanie uwierzytelniania Clerk i komponentów shadcn/ui, dostarczenie rzeczywistych funkcji pierwszego dnia. Ten sam cel, zupełnie inna podróż.

Dlaczego tak się dzieje?

Różnica nie leży w jakości frameworka, ale w optymalizacji ekosystemu. Next.js/React jest otoczony przez startupy wspierane przez venture capital, budujące narzędzia dla innych startupów:

• UI: shadcn/ui - kopiuj, wklej, wdrażaj
• Auth: Clerk/Supabase - konfiguracja w minuty
• Deploy: Vercel - git push równa się produkcji
• Wszystko inne: Jeśli startupy tego potrzebują, ktoś zbudował usługę

Ekosystem Angulara służy przedsiębiorstwom: potężny, elastyczny, nieskończenie konfigurowalny. Idealny(?) dla zespołów 50-osobowych i trucizna dla zespołów 3-osobowych.

\

Model mentalny #4 - Buduj rdzeń, wynajmuj kontekst

Ale nawet z odpowiednimi narzędziami istnieje jedna ostateczna pułapka: przymus budowania rzeczy, ponieważ możesz, a nie dlatego, że powinieneś. Ta pułapka zabija technicznie silne zespoły i więcej startupów, niż możemy sobie wyobrazić: budowanie rzeczy, o które nikt nie prosił, ponieważ możesz, a nie dlatego, że powinieneś.

Spędziliśmy co najmniej miesiąc łącznie na funkcjach, których nikt nie potrzebował. Niestandardowy OAuth, gdy istniał Auth0. Kolejka zadań oparta na Postgres, gdy istniał Redis + Celery. Terraform od pierwszego dnia, gdy konsola działała dobrze. Każda decyzja wydawała się produktywna, ale każda była autosabotażem w obliczu prawdziwych wyzwań, takich jak rozmowy z klientami lub inne działania związane z rozwojem klienta.

Wzorzec jest prosty: jeśli klienci nie wybiorą cię z tego powodu, nie buduj tego.

Moja zasada 50 dolarów

Jeśli SaaS kosztuje mniej niż 50 dolarów miesięcznie, nie możesz sobie pozwolić na jego budowę. Twój czas jest zbyt drogi.

Budowanie niestandardowego OAuth zajmuje 1-2 tygodnie łącznie na utrzymanie i dodawanie różnych dostawców OAuth. Przy tempie spalania startupów to 5000-15000 dolarów w czasie inżynieryjnym lub w czasie utraconej szansy. Auth0 jest darmowy dla maksymalnie 25 000 aktywnych użytkowników, a następnie 35 dolarów miesięcznie. Mógłbyś płacić za Auth0 przez 35 lat za to, co kosztuje jego jednorazowa budowa.

Więc nie chodzi o pieniądze, ale o priorytety i koszt alternatywny.

Wyjątek

Moim zdaniem buduj tylko wtedy, gdy nie możesz dowiedzieć się o użytkownikach bez tego.  Prosty przykład to sytuacja, gdy musisz przetestować, czy użytkownicy zapłacą za raporty generowane przez AI. Zbuduj najprostszą wersję, która udowadnia popyt. A wszystko inne próbuje się wymknąć. Tak, pomiń infrastrukturę, pomiń "robienie tego dobrze", pomiń najlepsze praktyki, które nie dostarczają funkcji, pomiń testy. Ponownie, bądź tak leniwy, jak to możliwe w pisaniu kodu.

Czego faktycznie używam

• Auth: Clerk (React-native, lepsze DX) lub Auth0 (skoncentrowany na B2B, gotowy dla przedsiębiorstw)
• Email: Resend (najpierw deweloperzy) lub SendGrid (sprawdzony w boju)
• Analityka: PostHog (darmowy do skalowania)
• Monitoring: Sentry (nie do pobicia dla błędów)
• Hosting: Cloudflare lub Vercel (jeśli całkowicie na Next.js)

To nie są rekomendacje, ale moje własne wybory zoptymalizowane pod kątem szybkości. Przypuszczam, że twój stos będzie się różnić, ale ta zasada nie.

\

\

Podsumowanie

LLM-y utowarowiły budowanie. Każdy junior z Claude może stworzyć ten niestandardowy system uwierzytelniania, z którego jesteś tak dumny. Twoja wartość nie leży już w tym, co możesz zbudować, ALE w wiedzy, czego nie budować.

Przywództwo to umiejętność oddzielania sygnałów od szumu. Prawdziwe starszeństwo oznacza posiadanie dyscypliny, aby zignorować 90% tego, co wiesz, i dostarczyć dzisiejsze rozwiązanie, a nie jutrzejszą architekturę.