KISS sau Mori: De ce Inginerii Seniori Eșuează la Startupuri

Primul meu startup a fost un eșec, și mai multe startup-uri din vecinătate au eșuat, de asemenea. Aveam: credite GCP de 100.000$, un inginer fondator care construise sisteme în întreprinderi, și go-to-market. Și am eșuat, nu pentru că am construit greșit, ci pentru că am construit bine. Aceasta a fost problema.

În timp ce ne-am petrecut timpul luptându-ne cu ceea ce părea un stack tehnologic "ne-optimal", am pierdut lucrul cel mai important: timp, impuls și, strategic, o oportunitate.

Această poveste nu este despre oameni fără bun simț. Aveam bun simț și știam că ar trebui să păstrăm lucrurile simple. Dar când modelul tău mental nu se potrivește situației, tot bunul simț este măturat. Iei decizii "corecte" care te omoară.

Aceasta nu este nici o poveste despre inginerie proastă. Este despre cum ingineria bună ucide startup-urile. Cum experiența care te face senior devine cea mai mare responsabilitate a ta. Cum "a face lucrurile corect" sau chiar "a face lucrurile simplu" înseamnă adesea a le face greșit.

Acest articol prezintă modele mentale pentru a te ajuta să iei deciziile corecte și să eviți greșelile pe care le-am făcut eu.

:::tip Pentru cine este acest articol: ingineri seniori care încep sau se alătură startup-urilor în fază incipientă. Dacă ai petrecut 5+ ani în întreprinderi sau Big Tech, acesta este avertismentul tău.

:::

\

Modelul Mental #1 - Infrastructura "Gratuită" Este Cea Mai Scumpă

100.000$ în credite GCP par un cadou, dar este o capcană. Te împinge spre supra-inginerie pentru că "este deja plătit." Primești instanțe de calcul, load balancers, registre de containere și instrumente enterprise care necesită configurare enterprise. Ce ai nevoie să obții? Un buton "push to deploy".

Sigur, poți construi fluxuri de lucru "deploy from GitHub to VM" pe GCP/AWS/Azure. Unele produse se apropie. Dar necesită pași suplimentari: configurarea Cloud Build, setarea rolurilor IAM, scrierea scripturilor de deployment, gestionarea secretelor și configurarea verificărilor de sănătate. Pierzi timp construind infrastructură de deployment înainte de a implementa produse reale.

Între timp, platforme precum Railway sau Fly.io îți oferă ceea ce startup-urile au nevoie cu adevărat: o mașină virtuală persistentă cu deployment start-and-go din GitHub. Ușor cum poate fi: îți împingi codul și se implementează. Doar o mașină virtuală gata de utilizare cu variabile de mediu, SSL, load balancers, loguri etc. Nu este "gratuit", dar este gata.

Creditele gratuite te împing spre supra-inginerie pentru că "sunt deja plătite." Te convingi că economisești bani în timp ce îți cheltuiești cea mai valoroasă resursă: timpul.

\

Modelul Mental #2 - "Minimal" <> "Simplu"

Principiul tradițional KISS ne spune să păstrăm software-ul nostru simplu. Dar în startup-uri, acesta este ținta greșită. Nu ar trebui să păstrezi SOFTWARE-ul simplu; ar trebui să păstrezi SOLUȚIILE simple.

Simplitatea reală ar trebui măsurată prin efortul total, nu prin complexitatea codului:

Efort Total = Construcție Inițială + Întreținere + Debugging + Adăugare Funcționalități + Actualizări de Securitate + Modificări de Scalare

Când construiești de la zero, deții toate acestea pentru totdeauna. Când folosești un serviciu, majoritatea acestora devin zero. Serviciul terț "umflat" este de fapt soluția simplă pentru că minimizează efortul total.

Exemplul meu OAuth

Inginerul nostru fondator a decis să construiască OAuth de la zero în loc să folosească o "bibliotecă necunoscută." O săptămână mai târziu, a trimis un PR: implementare curată OAuth cu token-uri JWT, rotație de token-uri de reîmprospătare, gestionare de sesiuni și control de acces bazat pe roluri. Fără dependențe, fără blocare de furnizor, doar cod pe care îl controlam.

Nu am respins PR-ul. Și aceasta a fost o greșeală. Aruncarea unei săptămâni de muncă ar fi zdrobit moralul. Dar creează complexitate în cod și îl pune pe șine greșite. Plus, nediscutarea abordării în prealabil a fost adevărata noastră greșeală. Am lăsat mândria inginerească să ia o decizie strategică.

Apoi, un client a avut nevoie de Microsoft OAuth și Google OAuth. Implementarea personalizată a însemnat zile de refactorizare, rotație de token-uri de reîmprospătare, cazuri de margine, RBA și alte lucruri. Fiecare adăugare "simplă" necesita o înțelegere profundă a autentificării noastre personalizate. Fiecare actualizare de securitate era a noastră pentru implementare. Fiecare cerință nouă era a noastră pentru codare.

Principii

Greșeala clasică a inginerului senior: optimizarea pentru control în loc de rezultate. În startup-uri, realitatea necesită inversarea completă a modului în care gândesc inginerii seniori:

1. OPREȘTE-TE din a gândi: "Aceasta este doar câteva zile de codare" \n ÎNCEPE să gândești: "Acestea sunt câteva zile în care NU codez produsul meu real"
2. OPREȘTE-TE din a gândi: "Pot construi acest lucru simplu" \n ÎNCEPE să gândești: "Pot rezolva acest lucru simplu prin a nu construi"
3. OPREȘTE-TE din a gândi: "Serviciile terțe adaugă complexitate" \n ÎNCEPE să gândești: "Serviciile terțe absorb complexitatea"

\

\

Modelul Mental #3 - Alegeri de confort

Am ales Angular pentru că inginerul nostru fondator îl cunoștea profund. Decizie inteligentă, nu? Folosește-ți punctele forte, livrează cod de calitate. Framework-ul era bun, DAR problema era ecosistemul său.

Capcana Ecosistemului

Angular este excelent și inginerul nostru putea construi orice cu el.

Dar "orice" lua timp doar pentru a începe. Configurarea deployment-ului, autentificării și componentelor UI de bază însemna configurare fără sfârșit înainte de a scrie o singură funcționalitate. În timp ce noi depanăm temele Angular Material, concurenții pot (și vor) folosi Next.js + Vercel și deja înregistrau utilizatori.

Compară doar cu calea Next.js + Vercel: implementează o aplicație schelet cu npx create-next-app în prima zi, adaugă autentificare Clerk și componente shadcn/ui, livrează funcționalități reale în prima zi. Aceeași destinație, călătorie complet diferită.

De ce se întâmplă acest lucru?

Diferența nu este calitatea framework-ului, ci optimizarea ecosistemului. Next.js/React este înconjurat de startup-uri susținute de capital de risc care construiesc instrumente pentru alte startup-uri:

• UI: shadcn/ui - copiază, lipește, livrează
• Auth: Clerk/Supabase - configurează în minute
• Deploy: Vercel - git push înseamnă producție
• Orice altceva: Dacă startup-urile au nevoie, cineva a construit un serviciu

Ecosistemul Angular servește întreprinderilor: puternic, flexibil, infinit personalizabil. Perfect(?) pentru echipe de 50 și o otravă pentru echipe de 3.

\

Modelul Mental #4 - Construiește Nucleul, Închiriază Contextul

Dar chiar și cu instrumentele potrivite, există o capcană finală: compulsia de a construi lucruri pentru că poți, nu pentru că ar trebui. Această capcană ucide echipe tehnice puternice și mai multe startup-uri decât ne putem imagina: construirea lucrurilor pe care nimeni nu le-a cerut pentru că poți, nu pentru că ar trebui.

Am petrecut cel puțin o lună în total pe funcționalități de care nimeni nu avea nevoie. OAuth personalizat când Auth0 exista. O coadă de job-uri bazată pe Postgres când Redis + Celery existau. Terraform din prima zi, când consola funcționa bine. Fiecare decizie părea productivă, dar fiecare era auto-sabotaj pentru a înfrunta provocări reale precum discuțiile cu clienții sau alte dezvoltări orientate spre client.

Modelul este simplu: dacă clienții nu te vor alege pentru asta, nu o construi.

Regula mea de 50$

Dacă un SaaS costă mai puțin de 50$/lună, nu îți permiți să îl construiești. Timpul tău este prea scump.

Construirea OAuth personalizat durează 1-2 săptămâni în total pentru întreținere și adăugarea diferitelor furnizori OAuth. La ratele de ardere ale startup-urilor, asta înseamnă 5.000-15.000$ în timp de inginerie, sau în timp de oportunitate pierdut. Auth0 este gratuit pentru până la 25.000 de utilizatori activi, apoi 35$/lună. Ai putea plăti pentru Auth0 timp de 35 de ani cu cât costă să îl construiești o dată.

Deci, nu este vorba despre bani, ci despre priorități și cost de oportunitate.

Excepție

În opinia mea, construiește doar dacă nu poți învăța despre utilizatori fără asta.  Un exemplu simplu este când trebuie să testezi dacă utilizatorii vor plăti pentru rapoarte generate de AI. Construiește cea mai simplă versiune care dovedește cererea. Și orice altceva încearcă să alunece. Da, sari peste infrastructură, sari peste "a face lucrurile corect", sari peste cele mai bune practici care nu livrează funcționalități, sari peste teste. Din nou, fii cât mai leneș posibil în scrierea codului.

Ce Folosesc Eu De Fapt

• Auth: Clerk (React-native, DX mai bun) sau Auth0 (orientat spre B2B, pregătit pentru întreprinderi)
• Email: Resend (prioritate pentru dezvoltatori) sau SendGrid (testat în luptă)
• Analytics: PostHog (gratuit până la scalare)
• Monitoring: Sentry (imbatabil pentru erori)
• Hosting: Cloudflare sau Vercel (dacă ești all-in pe Next.js)

Acestea nu sunt recomandări, ci propriile mele alegeri optimizate pentru viteză. Presupun că stack-ul tău va fi diferit, dar acest principiu nu.

\

\

Concluzie

LLM-urile au comodificat construirea. Orice junior cu Claude poate crea acel sistem de autentificare personalizat de care ești atât de mândru. Valoarea ta nu mai constă în ceea ce poți construi, CI în a ști ce să nu construiești.

Leadership-ul este abilitatea de a separa semnalele de zgomot. Adevărata senioritate înseamnă a avea disciplina de a ignora 90% din ceea ce știi și de a livra soluția de astăzi, nu arhitectura de mâine.