Nudny stack w dobrym znaczeniu tego słowa
Dobieramy technologię pod projekt, nie pod modę ani pod to, czego akurat chcemy się nauczyć.
System, który ma żyć pięć lat, potrzebuje narzędzi, które przez te pięć lat będą miały kogo zatrudnić.
Frontend
- TypeScript
- Vue
- Nuxt
- React
- React Native
- Flutter
TypeScript wszędzie, bez wyjątków — błąd wychwycony przez kompilator jest o dwa rzędy wielkości tańszy niż ten sam błąd znaleziony przez użytkownika.
Więcej
Vue i Nuxt jako domyślny wybór przy nowych projektach: renderowanie po stronie serwera, routing i optymalizacja obrazów działają od razu, bez składania frameworka z pięciu bibliotek. React tam, gdzie zespół klienta już go zna albo istniejący kod jest w nim napisany.
Backend
- Node.js
- PHP
- PostgreSQL
- Redis
Node.js jako domyślny runtime, bo jeden język po obu stronach realnie skraca czas wdrożenia się w projekt.
Więcej
PHP, gdy przejmujemy istniejący system albo integrujemy się z takim, którego nie przepisujemy. PostgreSQL do wszystkiego, co ma strukturę i musi być spójne; Redis do kolejek, sesji i tego, co wolno stracić przy restarcie.
Infrastruktura
- Vercel
- Google Cloud
- Docker
- GitHub Actions
Konta zakładane na Twoje dane, nie na nasze — to jedyna konfiguracja, w której zmiana wykonawcy nie oznacza migracji.
Więcej
Vercel przy aplikacjach webowych i stronach, Google Cloud przy systemach z własnym backendem i danymi, które muszą zostać w konkretnym miejscu. Docker, żeby środowisko lokalne i produkcyjne były tym samym środowiskiem. GitHub Actions do testów i wdrożeń — wdrożenie ma być nudne i powtarzalne.
AI
- modele językowe
- wyszukiwanie semantyczne
- ekstrakcja z dokumentów
Modele językowe wdrażane tam, gdzie skracają konkretną pracę, a nie tam, gdzie dobrze wyglądają na demie.
Więcej
Wyszukiwanie semantyczne do wiedzy firmowej, której nikt nie potrafi znaleźć zwykłą wyszukiwarką po słowach kluczowych. Ekstrakcja z dokumentów tam, gdzie ktoś dziś przepisuje dane z PDF-ów do systemu. Każde z tych zastosowań ma mierzalny efekt — jeśli nie da się go zmierzyć, odradzamy wdrożenie.
Szerzej
Jak wybieramy
Trzy pytania, w tej kolejności. Czy ta technologia rozwiąże problem, który faktycznie mamy? Czy za trzy lata znajdziemy kogoś, kto ją zna? Czy da się ją zastąpić, jeśli okaże się ślepą uliczką?
Technologia, która przechodzi tylko pierwsze pytanie, jest ryzykiem przerzuconym na klienta. Większość spektakularnych porażek wdrożeniowych, które oglądaliśmy z boku, zaczynała się od wyboru narzędzia, którego w regionie używa pięć osób.
Czego nie używamy
Nie budujemy na własnym, zamkniętym silniku — to najskuteczniejszy mechanizm uzależniający, jaki znamy, i dlatego go nie mamy. Nie wprowadzamy technologii, która nie wyszła jeszcze ze statusu eksperymentalnego, do systemu, który ma działać produkcyjnie. Nie przepisujemy działającego kodu na nowszy framework tylko dlatego, że jest nowszy.
Co to znaczy dla Ciebie
Repozytorium, prawa majątkowe i wszystkie konta infrastrukturalne są Twoje od pierwszego dnia. Dokumentacja i testy powstają tak, żeby inny zespół mógł przejąć system bez naszego udziału. To nie jest gest dobrej woli — to warunek, żeby wybór wykonawcy dało się kiedyś odwrócić.
Masz pomysł? Porozmawiajmy.
Pierwsza rozmowa jest bezpłatna. Odpowiadamy w jeden dzień roboczy.