Cum alegi stack-ul tehnologic pentru startup — ghid practic

«Vrem React, Node.js, MongoDB și AWS.» Auzim asta în prima discuție cu nouă din zece fondatori. De obicei, nu au ales — au citit lista undeva. Ghidul de față explică ce contează cu adevărat la alegerea stack-ului tehnologic: nu numele tehnologiilor, ci criteriile care separă o decizie defensible de una aleatoare.

Ce este un stack tehnologic

Un stack tehnologic este ansamblul de tehnologii folosite pentru a construi și rula aplicația. Include patru straturi:

Fiecare strat are zeci de opțiuni. Vestea bună: pentru majoritatea startup-urilor, diferențele de performanță între opțiunile mature sunt neglijabile. Vestea proastă: o alegere greșită poate adăuga luni de muncă suplimentară și costuri de refactorare.

Cei patru factori care contează cu adevărat

Multe articole despre alegerea stack-ului încep cu comparații tehnice: benchmark-uri, sintaxă, viteza de randare. Acestea sunt rareori factorii decisivi. Factorii care contează sunt patru:

1. Disponibilitatea dezvoltatorilor

Acesta este, în practică, factorul cel mai important. Un stack pe care nu îl poate nimeni întreține este un stack greșit, indiferent cât de elegant este tehnic. Dacă alegi Elixir și Phoenix în București în 2026, vei avea probleme să găsești dezvoltatori. Dacă alegi React și Node.js, vei avea sute de candidați.

Acest lucru nu înseamnă să alegi doar ce e popular. Înseamnă să evalueezi disponibilitatea talentului pe termenul de viață al proiectului (3-5 ani minim) în locația în care operezi. Un stack exotic cu 2 dezvoltatori disponibili în oraș este un risc operațional real.

2. Ecosistemul de pachete și librării

Fiecare aplicație folosește zeci de librării terțe: autentificare, plăți, export PDF, generare de grafice, CMS headless, email tranzacțional. Un stack cu un ecosistem matur (npm pentru JavaScript, PyPI pentru Python) are soluții testate pentru aproape orice nevoie. Un stack niche înseamnă să scrii singur integrări care în alte ecosisteme sunt un singur npm install.

Măsoară maturitatea ecosistemului prin: numărul de pachete disponibile, frecvența actualizărilor, calitatea documentației și numărul de întrebări pe Stack Overflow. Nu prin PR-ul framework-ului.

3. Costul de operaționalizare

Un server VPS pe Hetzner costă €10-50/lună pentru o aplicație cu câteva mii de utilizatori. Aceeași aplicație pe AWS, configurată «corect» cu Load Balancer, RDS multi-AZ, ElastiCache și CloudFront, costă €300-800/lună. Ambele rulează aceeași aplicație. Diferența: AWS adaugă disponibilitate și scalare automată care, pentru un startup sub 50.000 de utilizatori, probabil nu sunt necesare.

Costul de infrastructură nu este doar factura lunară. Este și timpul de mentenanță: configurare, monitoring, backup-uri, actualizări de securitate, depanare. Serverless (Vercel, Cloudflare Workers) reduce acest timp aproape de zero, dar blochează într-un vendor și are costuri imprevizibile la scară.

4. Tipul aplicației pe care o construiești

O aplicație cu transmisie video live are cerințe diferite de un magazin online. Un sistem de procesare batch cu milioane de înregistrări are cerințe diferite de un dashboard analitic cu 50 de utilizatori concurenți. Stack-ul trebuie să match-uiască profilul de workload:

• Aplicație CRUD cu interfață web — majoritatea aplicațiilor de business: React/Next.js + Node.js sau Python + PostgreSQL. Simplu, matur, previzibil.
• Procesare intensivă de date — ETL, ML, analytics: Python (Pandas, NumPy) + PostgreSQL + Redis pentru cache. Python domină aici prin ecosistemul științific.
• Real-time (chat, live tracking, gaming) — Go sau Elixir pe backend pentru concurență masivă pe conexiuni WebSocket. Node.js cu Socket.io pentru versiuni mai simple.
• Conținut editorial / blog — site static generat (Astro, Next.js SSG, Hugo). Niciun server runtime, PSI 100, cost hosting zero pe Cloudflare Pages.

Deciziile care nu contează aproape deloc

Unele dezbateri tehnice consumă timp disproporționat față de impactul real. Trei exemple:

React vs Vue

Ambele sunt framework-uri mature, cu performanță echivalentă, ecosistem solid și documentație bună. React are piața de talente cea mai mare (mai ușor să angajezi). Vue are o curbă de învățare mai blândă (mai rapid pentru echipe noi). Alegerea nu va determina succesul sau eșecul startup-ului. Dacă cineva îți spune că una este «net superioară», întreabă ce interese are.

PostgreSQL vs MongoDB

Pentru 90% din aplicațiile de business, PostgreSQL este răspunsul corect. Este o bază de date relațională ACID, suportă JSON nativ (pentru date semi-structurate), are extensii pentru full-text search și analiză geospațială, și rulează în producție la companii de la startup-uri la bancă. MongoDB are sens când datele sunt cu adevărat fără schemă și cresc prin acumulare de documente fără relații clare — un scenariu mai rar decât sugerează popularitatea sa.

Argumentul «MongoDB este mai rapid» este fals la paritate de configurare. Argumentul «MongoDB scalează mai bine» a fost adevărat în 2012; astăzi, PostgreSQL cu partitioning și read replicas scalează la sute de milioane de rânduri fără probleme.

Microservicii vs Monolith

Un startup cu 3 dezvoltatori nu are nevoie de microservicii. Un monolith bine structurat (module clar separate, baze de date per modul opțional) este mai rapid de construit, mai ușor de depanat și mai ieftin de operat. Microserviciile adaugă complexitate operațională (service discovery, distributed tracing, network failures) care se justifică doar la scară organizațională — echipe separate care trebuie să deploy independent.

Regula pragmatică: începe cu monolith. Extrage microservicii când o componentă are nevoie de scalare independentă sau un ciclu de release separat. Nu invers.

Cum arată o decizie defensible

O decizie de stack defensible poate fi explicată în trei propoziții: «Am ales React pentru frontend pentru că piața de talente în București are cel mai mare volum de dezvoltatori React, ceea ce reduce riscul de staffing. Am ales PostgreSQL pentru baza de date pentru că datele noastre sunt relaționale (clienți, comenzi, produse) și necesită consistență ACID. Am ales Hetzner pentru hosting pentru că, la sub 10.000 de utilizatori, costul AWS nu se justifică.»

Compare cu o decizie indefensibilă: «Am ales Vue, NestJS și MongoDB pentru că le-am folosit la un proiect anterior.» Aceasta nu este o decizie — este inerție. Nu e neapărat greșită, dar nu este justificată.

Cele cinci greșeli frecvente

1. Alegerea după ce e la modă. «Blockchain», «edge computing», «AI-native» — un startup care alege un stack pentru PR-ul tehnic ajunge să rescrie aplicația în 18 luni. Alege pentru cerințele de business, nu pentru titlul de pe TechCrunch.
2. Over-engineering de la ziua 1. Kubernetes, event sourcing, CQRS, message queues distribuite — pentru un MVP cu 100 de utilizatori, acestea sunt overhead pur. Începe simplu, adaugă complexitate când datele o cer.
3. Ignorarea costurilor pe termen lung. AWS este gratuit sau ieftin în primul an (Free Tier). În al doilea an, factura poate tripla fără să schimbi nimic în aplicație. Modelează costurile pentru 10x trafic înainte să alegi.
4. Mixarea a prea multe tehnologii. Un startup cu React frontend, Node.js microservice pentru auth, Python microservice pentru analytics, Go microservice pentru search și Ruby pentru admin panel are cinci stive de mentenanță cu trei dezvoltatori. Fiecare tehnologie adaugă cost fix de mentenanță.
5. NU alege înainte de a defini cerințele. Multe echipe aleg stack-ul înainte de a specifica ce construiesc. Rezultatul: tehnologia dictează produsul, nu invers. Mai întâi scrie cerințele (ce trebuie să facă aplicația, pentru câți utilizatori, cu ce constrângeri), apoi alege stack-ul care le match-uiește cel mai bine.

Stack-uri recomandate pe profil de proiect (2026)

Tabelul de mai jos nu este exhaustiv, ci un punct de pornire pentru discuție. Fiecare recomandare reflectă maturitatea ecosistemului, disponibilitatea talentului în România și costul de operaționalizare rezonabil.

Întrebări de evaluare — test pentru fondatori

Înainte de a accepta o recomandare de stack (de la noi sau de la altcineva), pune aceste cinci întrebări. Răspunsurile corecte sunt cele specifice, nu cele generice:

1. De ce această tehnologie și nu alta? Răspunsul trebuie să conțină criterii concrete (disponibilitate talente, cost, ecosistem), nu preferințe personale.
2. Cât costă infrastructura la 10x trafic? Dacă răspunsul este «depinde», cere un calcul. Serverless care costă €50/lună la 1.000 de utilizatori poate costa €5.000/lună la 100.000.
3. Cât de greu este să schimb o componentă mai târziu? Dacă frontend-ul este cuplat strâns cu backend-ul (SSR cu un framework specific), schimbarea unuia înseamnă refactorarea celuilalt. Arhitectura decuplată costă puțin mai mult acum, economisește masiv mai târziu.
4. Există un plan de migrare dacă tehnologia devine nesuportată? Framework-uri și servicii mor. Un stack matur are un path de migrare documentat. Unul exotic nu.
5. Cine va întreține asta peste 2 ani? Dacă răspunsul este «doar persoana care o construiește», ai un risc de bus factor. Tehnologii cu piață mare de talente reduc acest risc.

Citește în continuare

• Next.js vs WordPress — când merge fiecare
• Hetzner vs AWS — comparație reală de cost
• MVP vs prototip — alegerea potrivită pentru stadiul startup-ului
• Dicționar IT pentru non-tehnici