Napisz do nas

Punktem wyjścia jest cel biznesowy, nie lista technologii: co ma się poprawić, dla kogo i jak to zmierzyć. Dopiero po ustaleniu celu i zakresu dobierana jest architektura i stos technologiczny.

Zakres, cena i termin ustalane są przed startem projektu, razem z tym, co do zakresu nie wchodzi. Granica ustalona na początku jest tańsza niż zaskoczenie w trakcie realizacji.

Backend stoi zwykle na Node.js, NestJS i TypeScript, dane w relacyjnej bazie przez TypeORM, infrastruktura opisana w Terraform i uruchamiana w Dockerze. Integracje z modelami językowymi budowane są wokół Model Context Protocol. Dobór konkretnego stosu zależy od skali i wymagań danego projektu, nie z góry ustalonej listy.

Rozróżnienie między projektem od zera a modernizacją lub integracją istniejącego rozwiązania ustala zakres, ryzyko i koszt już na starcie. Przegląd architektury poprzedza decyzję w obu przypadkach.

Architektura jest dobierana do skali procesu, nie do mody technologicznej. Monolit z czytelnymi granicami modułów bywa lepszym wyborem niż mikrousługi, których nikt później nie utrzyma - podział na osobne usługi ma sens dopiero przy konkretnym powodzie, żeby je rozdzielić.

Kod, testy i dokumentacja zostają po stronie klienta po każdym oddanym etapie, więc dalszy rozwój nie zależy wyłącznie od dostępności jednej osoby w danym tygodniu. W zamian znika warstwa pośrednia między decyzją a jej wykonaniem: architekturę, kod i wdrożenie prowadzi ta sama osoba od pierwszej rozmowy do produkcji.

Model fixed-price sprawdza się przy zamkniętym, wydzielonym zakresie, time & materials tam, gdzie praca ma charakter ciągły. Dobór modelu zależy od dynamiki projektu i zakresu odpowiedzialności. Doradztwo techniczne bywa osobnym, krótkim zleceniem.

Integracja rzadko psuje się w dniu wdrożenia - psuje się kilka miesięcy później, gdy jeden system zmieni format danych, a drugi milczy o awarii. Ponowienia, kolejka nieudanych zdarzeń i alert na zatrzymany przepływ są projektowane razem z samą integracją, nie dokładane po pierwszej awarii.

Wymogi RODO, dostępność WCAG i bezpieczeństwo samego procesu wytwarzania są zamieniane w automatyczne bramki w CI, które zatrzymują build, jeśli wymóg przestaje być spełniony.