Tech stack to nie wybór narzędzia. To decyzja na kilka wersji w przód.

Każdy produkt IT ma swój typowy cykl: identyfikacja problemu, planowanie MVP, wybór stacku, implementacja, deploy, iteracje. Pierwsze dwa etapy potrafią pochłonąć tygodnie - i słusznie, bo to w nich kształtuje się zamysł produktu. Gdy pomysł się skrystalizuje, pojawia się przyspieszenie. Jak najszybciej do kodu. Jak najszybciej do czegoś, co można pokazać, przetestować, zebrać feedback.

Efekt? Wybór stacku traktowany jak formalność. “Aplikacja może działać na React, Angularze czy Astro - w końcu frontend to frontend, jaka różnica?” Spora. Bo ten etap będzie rzutował na cały projekt - a szczególnie na koszty, które pojawią się tam, gdzie nikt ich nie planował.

Trzy kryteria, zero pytań

Typowy wybór stacku opiera się na jednym z trzech kryteriów. Znajomość - “znam React, więc React”. Prostota startu - “w Vue postawię MVP w weekend”. Albo hype - “Svelte nie potrzebuje virtual DOM, jest szybszy od wszystkiego”.

Każde z nich brzmi sensownie. Żadne nie odpowiada na pytanie: czym ten produkt ma być za pół roku i jakie wymagania z tego wynikają?

A to właśnie powinno być kryterium zero.

Stack jest pochodną pytania

W notatce o granicy MVP padła teza: zakres MVP wynika z pytania, nie z listy funkcji. Z wyborem stacku jest tak samo - tyle że konsekwencje ciągną się dłużej.

Prosty przykład. Strona, która ma dostarczać treści i dobrze się pozycjonować, potrzebuje SSR i statycznego renderowania. Aplikacja z rozbudowaną logiką po stronie klienta - nie. To nie kwestia preferencji między jednym frameworkiem a drugim. To kwestia tego, czym ten produkt ma być za pół roku.

Jeśli pytanie brzmi “potrzebuję landing page z blogiem” - wybór frameworka SPA to niepotrzebna komplikacja. Jeśli pytanie brzmi “buduję dashboard z real-time danymi” - statyczny renderer to ślepa uliczka. Stack wynika z pytania, a nie z widzimisię twórcy.

Stack pod MVP kopie grób produktowi

Stack dobrany tylko i wyłącznie pod MVP stawia produkt pod ścianą przy pierwszej poważnej zmianie. Dalej padają już tylko strzały.

Monolit do rozbicia.
Frontend do przepisania.
Baza do migracji.

Każda iteracja droższa od poprzedniej - bo stack nie był dobrany pod wizję na kilka wersji w przód.

Druga skrajność jest równie kosztowna - stack projektowany pod wszystkie możliwe wersje naraz to overengineering, który tak jak drift MVP potrafi zatrzymać projekt zanim jeszcze wystartuje, bo mikroserwisy od dnia pierwszego wymagają osobnego repozytorium na każdy serwis, każdy serwis wymaga dedykowanego CI/CD pipeline’u, pipeline wymaga API gateway’a który routuje ruch którego jeszcze nie ma, a to wszystko dla produktu który nie zdobył jeszcze pierwszego użytkownika - i zanim ktokolwiek zobaczy landing page, architektura na wyrost zjadła cały czas który powinien iść w walidację pomysłu.

Nie chodzi o to, żeby trafić w środek między jednym a drugim. Chodzi o to, żeby wybrać jak najmniej złożony stack, który wystarczy na najbliższe iteracje produktu.

Nie sztuka zabić mrówkę strzelając do niej z armaty.

Czego stack nie rozwiąże

“Dobry stack = sukces produktu.” Nie. Stack to warstwa narzędziowa. Za sukcesem produktu stoją decyzje biznesowe, architektoniczne i marketingowe, które mają o wiele większy wpływ niż wybór frameworka. Stack da się przepisać. Złych decyzji produktowych nie naprawisz zmianą frameworka.

Narzędzia AI coraz sprawniej generują kod w dowolnym frameworku. Wiedza specyficzna dla konkretnego narzędzia traci na znaczeniu. To, co zostaje, to umiejętność oceny trade-offów - kiedy wybrać prostotę, kiedy elastyczność, kiedy wydajność.

Wiedza frameworkowa przestaje być przewagą. Umiejętność podejmowania decyzji - nie.

Pytanie, które zostaje

Jeśli stack dobiera się pod pytanie produktowe, a nie pod preferencje - to co się dzieje, gdy to pytanie zmienia się w trakcie budowania? Jak daleko w przód da się realistycznie planować, zanim planowanie zamieni się w zgadywanie?

W newsletterze rozwijam tego rodzaju tematy głębiej. Zapisz się.