Ekspertyza · Oprogramowanie na zamówienie

System zbudowany pod sposób działania Waszej organizacji, a nie pod przypadek ogólny.

Budujemy systemy od zera, gdy żaden produkt na rynku nie pasuje: platformy z wieloma aplikacjami i wspólną bazą danych, konektory do systemów bez API, potoki, które czytają dokumenty i przepływy pieniędzy, oraz programy, których wynikiem nie jest ekran, lecz dossier produkcyjne. Na końcu przekazujemy repozytorium, dokument uruchomienia i dostępy.

Omów projekt

Już zbudowaneWybrałem cztery własne systemy z różnych dziedzin właśnie po to, żeby nie wyglądały jak cztery warianty tej samej strony, i uruchomiłem dziś testy każdego z nich. Monorepo z 3 aplikacjami i 12 pakietami, 486 plików TypeScript i 68 plików testowych, 151 commitów, czyste drzewo robocze. System odpytywania dwóch portali B2B bez publicznego API: 38 testów zaliczonych w 0,52 s, na rzeczywistych odpowiedziach zapisanych jako fixtures. Potok, który czyta powiadomienia bankowe z e-maila i PDF oraz zapisuje je do Postgresa z deduplikacją przez fingerprint. I generator dokumentacji inżynieryjnej w Pythonie, z 44 zaliczonymi testami w 0,50 s. Liczby pochodzą z moich uruchomień z 6 września 2026, nie z README.

„Na zamówienie” oznacza, że system jest pisany pod sposób, w jaki ludzie już pracują, a nie odwrotnie. Ma koszt, o którym uczciwie trzeba powiedzieć z góry: ktoś musi go utrzymywać, a tym kimś jesteśmy my albo Wasz zespół. Dlatego pierwsze pytanie, jakie zadajemy, nie brzmi, co chcecie zbudować, tylko czy istnieje produkt, który już robi 80% pracy. Jeśli istnieje, mówimy to, nawet jeśli oznacza to, że to nam nie dacie zlecenia. To, co zostaje po tym pytaniu — część, której nie kupuje się gotowej — to dokładnie to, co budujemy dobrze.

Skala widać wyraźniej z czterech różnych systemów niż z listy technologii. Pierwszy to platforma dla instytucji spektaklowej: monorepo z trzema aplikacjami (strona publiczna, panel administracyjny, API) i dwunastoma wspólnymi pakietami — bilety, handel, treści, powiadomienia, zwroty, bezpieczeństwo. Drugi na żądanie odpytuje portale B2B touroperatorów, którzy nie publikują żadnego API: programowe uwierzytelnianie, powrót do logowania, gdy sesja wygasa, oraz parser testowany na rzeczywistych odpowiedziach zapisanych w plikach. Trzeci czyta powiadomienia bankowe z e-maili i zestawień PDF i zapisuje je w Postgresie. Czwarty nie ma żadnego ekranu: to program, który generuje model, listę materiałów i rysunki maszyny przemysłowej.

To, co podtrzymuje taki system, to nie stos technologiczny, lecz reguły zapisane przed pierwszym ekranem. W platformie dla instytucji widowiskowej umowa wdrożeniowa utrwala w tekście rzeczy, które inaczej negocjuje się na każdym spotkaniu: pieniądze są trzymane w całych najmniejszych jednostkach, razem z walutą; dostępność miejsca wynika wyłącznie z trwałej rezerwacji w bazie danych, nigdy z pamięci podręcznej; krytyczne zlecenia mają klucze idempotencji; ścieżki P0 i P1 zawodzą w trybie zamkniętym, a nie otwartym; dane karty nigdy nie są przechowywane. Te reguły zapisuje się na początku, bo zapisane na końcu oznaczałyby przepisanie systemu.

Na końcu przekazuje się trzy rzeczy, nie jedną: repozytorium z całą jego historią, dokument, który mówi, jak uruchomić je na czystym serwerze, oraz dostęp. W naszym katalogu projektów znajduje się 150 repozytoriów git, 103 pliki README i 19 dokumentów uruchomieniowych lub przekazania — policzone dziś, nie oszacowane. Zasady własności zapisujemy w umowie przed startem i są proste: kod napisany specjalnie dla Ciebie należy do Ciebie, biblioteki stron trzecich pozostają na swoich licencjach, a nasze komponenty wielokrotnego użytku i nasze produkty są licencjonowane, a nie przenoszone. Jeśli część pracy lepiej rozwiązuje któryś z naszych produktów, mówimy to dokładnie tak, aby od początku było wiadomo, co kupujesz i co otrzymujesz.

Co obejmuje

Praca, komponent po komponencie

Zapisujemy reguły domeny przed pierwszym ekranem

Umowa wdrożeniowa, w tekście, która utrwala słownictwo i niezmienniki: co oznacza zarezerwowane miejsce, co oznacza otrzymana płatność, co przechodzi w tryb zamknięty, gdy usługa nie odpowiada. W platformie dla instytucji widowiskowej reguły są jawne — pieniądze w całych najmniejszych jednostkach wraz z walutą, dostępność wyłącznie z trwałych rezerwacji w bazie danych, klucze idempotencji przy krytycznych zleceniach, pamięć podręczna nigdy nie jest źródłem prawdy dla stanu magazynowego, dane karty nigdy nie są przechowywane. To reguły, które sprawdza się w kodzie, a nie zasady.

Budujemy rdzeń na testach działających bez żywego systemu

Rzeczywiste odpowiedzi systemów zewnętrznych zapisuje się jako fixture, a parser testuje się na nich, a nie na portalu, który może być niedostępny właśnie w dniu, w którym pracujesz. W systemie zapytań do portali lotniczych zestaw testów działa w 0,52 sekundy i przechodzi w całości; testy, które faktycznie dotykają portali, są oznaczone osobno i wymagane są wprost. To samo rozdzielenie istnieje we wszystkich czterech systemach: to, co można zweryfikować na stole, weryfikuje się na stole.

Przekazujemy repozytorium, uruchomienie i dostęp

Nie plik zip. Repozytorium z historią commitów, dokument opisujący, jak podnieść system na pustej maszynie — baza danych, zmienne środowiskowe, usługa systemowa, serwer WWW z przodu — oraz dostęp, który czyni go Twoim. W naszym katalogu projektów istnieje dziś 150 repozytoriów git, 103 README i 19 dokumentów typu DEPLOY lub HANDOVER; taka forma przekazania jest zwyczajem, a nie wyjątkiem.

Gdy cudzy system nie ma API, mówimy, jakie ryzyko bierzesz

Portale B2B, które odpytywujemy, nie publikują interfejsu programistycznego, więc uwierzytelnianie odbywa się jak u użytkownika, z ciasteczkiem sesji i kluczem połączenia, a po wygaśnięciu jest odtwarzane automatycznie. Ryzyko jest zapisane w README projektu, a nie odkrywane później: uwierzytelnianie programistyczne jest szarą strefą względem warunków użytkowania portalu, a przy intensywnym wolumenie produkcyjnym właściwym rozwiązaniem jest poprosić operatora o jego oficjalne API. Klient ma prawo dowiedzieć się tego przed podpisaniem, nie po.

Dokumenty trafiają tylko raz, nawet jeśli czytamy je dziesięć razy

Każda transakcja wyodrębniona z powiadomienia bankowego lub z wyciągu PDF otrzymuje identyfikator zewnętrzny obliczony jako odcisk SHA-256 nad jej polami, a wstawienie do Postgresa odbywa się przez `ON CONFLICT (external_id) DO NOTHING`. Praktyczny skutek: skrzynkę pocztową można odczytywać dowolną liczbę razy, a saldo się nie dubluje. Bez tej reguły każdy pipeline ingestii kończy z duplikatami, czyli z problemem księgowym.

Klasyfikacja z użyciem modelu odbywa się przez narzędzia, a nie przez swobodny tekst

Model nie zapisuje zdania, które potem my zgadujemy: dostaje siedem narzędzi — płatność od klienta, wynagrodzenie, podatek, płatność do wierzyciela, wydatek operacyjny, nieznane — i musi wybrać jedno, ze wskaźnikiem pewności między 0 a 1. Do przybliżonego dopasowania nazw kontrahentów istnieje osobny rezerwuar, oparty na podobieństwie wektorów. „Nieznane” to prawidłowe wyjście, z uzasadnieniem, a nie ukryta porażka.

Czasem wynikiem nie jest ekran, lecz teczka

Własny system w Pythonie generuje trójwymiarowy model maszyny przemysłowej, zestawienie materiałów ze statusem zwolnienia na każdej pozycji, plan weryfikacji, schemat okablowania i arkusze PDF — z jednego polecenia, tak aby nic z pakietu nie mogło zostać w tyle za modelem. Ma 44 testy, które przechodzą w pół sekundy i sprawdzają reguły inżynierskie, nie tylko kod: że aktywny obszar ma dokładnie jeden metr sześcienny, że żadna pozycja w zestawieniu materiałów nie pozostaje bez wiersza weryfikacji, że maszyna nigdy nie ekstruzuje w spoczynku.

Ciągły pomiar to inna dyscyplina niż zapytanie na żądanie

Własny system jednocześnie pobiera wiele stacji radiowych za pomocą `ffmpeg`, lokalnie transkrybuje przy użyciu modelu open-source, a następnie wyszukuje reklamy z przejrzystym wynikiem na grupach sygnałów w języku rumuńskim i rosyjskim, z konfigurowalnym progiem, i grupuje tę samą reklamę nadawaną na różnych stacjach przez audioodcisk typu chromaprint — ponieważ transkrypcje się rozchodzą, ale dźwięk jest identyczny. Ma 81 testów, które przechodzą w 1,14 sekundy. System działający bez nadzoru potrzebuje liczników pokrycia, ponowień z wypożyczeniem zadania i autotestu, w przeciwnym razie milknie, gdy się psuje.

Mówimy też, czego nie budujemy

Nie budujemy od zera tego, co rozwiązuje się istniejącym produktem, naszym albo cudzym, tylko dlatego, że praca byłaby większa. Nie przejmujemy systemów, których nie możemy uruchomić lokalnie, z danymi testowymi, do końca pierwszego etapu. I nie uruchamiamy systemu zależnego od zewnętrznego dostawcy, zanim nie sprawdzimy, jakie ma on publiczne wejście — ta weryfikacja jest pierwsza, nie ostatnia.

Jak to wygląda

Trasa, krok po kroku.

Wyznaczamy zakres i zapisujemy reguły

Etap czytania systemów i rozmów z osobami, które dziś wykonują tę pracę, zakończony krótkim dokumentem ze słownictwem, inwariantami i tym, co domyka się na stałe. Dostarczamy ten dokument nawet wtedy, gdy nie dochodzi do budowy — jest przydatny także bez nas. Zawiera też listę zewnętrznych systemów, od których zależy praca, oraz sprawdzenie, jakie publiczne wejście ma każdy z nich, bo stamtąd biorą się niespodzianki.

Budujemy rdzeń, z jego testami, przed ekranami

Reguły domeny, modele danych, analizatory, obliczenia — plus testy działające bez żywych systemów, na fixturach przechwyconych z rzeczywistych odpowiedzi. Dostarczamy zestaw testów i jego wynik, wraz z komendą uruchomienia, aby można było uruchomić go samodzielnie. Rdzeń, którego nie da się testować bez środowiska produkcyjnego, to rdzeń, którego nie możemy później szybko naprawić.

Nakładamy interfejs i integracje na rdzeń

Panel administracyjny, ekrany publiczne, punkty wejścia dla innych systemów. Tutaj łączą się zewnętrzni dostawcy, każdy z własnym adapterem i wariantem symulacji, aby system dało się uruchomić w całości bez rzeczywistych kont. Dostarczamy też lokalny tryb uruchamiania, z bazą danych i usługami podniesionymi z kontenerów.

Uruchamiamy i przekazujemy

Instalacja na uzgodnionej infrastrukturze, usługa systemowa, serwer WWW z przodu, logi i ich rotacja, autotest. Potem przekazanie: repozytorium, dokument uruchomienia napisany dla pustej maszyny, dostęp i przegląd tego, co jeszcze zostało do zrobienia. To, co nie zdążyło wejść do prac, zapisuje się jako lista, a nie zostawia niewypowiedziane.

Trzy kroki i ich kolejność, a to jest połowa pracy. Najpierw reguły domeny zapisane w tekście — co oznacza zarezerwowane miejsce, jak trzyma się pieniądze, co zamyka się, gdy usługa milknie. Potem rdzeń z testami, który działa na rzeczywistych odpowiedziach zapisanych jako fixture, bez żywych systemów. Na końcu uruchomienie i przekazanie: repozytorium, dokument dla pustej maszyny, dostęp. Strzałka wstecz od kroku trzeciego do pierwszego jest realna: to, co wychodzi na jaw przy uruchomieniu, zmienia reguły, nie jest pod nimi ukrywane.

Dane

Czego dotykamy, gdzie to leży i jak długo zostaje

Pytania, które zadaje każdy, kto ma inspektora ochrony danych — postawione tutaj, zanim on je zada.

Gdzie działa i kto trzyma klucz: System działa na infrastrukturze uzgodnionej pisemnie na początku: wasz serwer, serwer administrowany przez nas albo dostawca hostingu wybrany wspólnie. Cztery powyższe systemy działają między sobą różnie — jeden jako usługa systemowa za serwerem WWW, jeden z kontenerów, jeden jako zaplanowany proces na lokalnej maszynie, jeden tylko na żądanie, na stacji roboczej. Wybór wynika z ograniczeń danych, a nie z przyzwyczajenia.
Poświadczenia nie siedzą w kodzie i, tam gdzie to możliwe, także nie na dysku: Hasła i klucze są odczytywane ze zmiennych środowiskowych, a plik, który je zawiera, jest ograniczony do bieżącego użytkownika. W konektorze do systemu zewnętrznego token sesji jest przechowywany wyłącznie w pamięci i odnawiany po wygaśnięciu albo przy pierwszej odmowie — hasło i token nie są zapisywane w żadnym pliku. Reguła jest sprawdzana podczas przeglądu: klucz, który trafił do repozytorium, jest incydentem, a nie przeoczeniem.
Dane wchodzące z dokumentów: Gdy system czyta e-maile lub PDF-y, dotyka rzeczywistych danych biznesowych: kwot, dat kalendarzowych, nazw kontrahentów, numerów kont. Są one przechowywane w bazie danych odbiorcy, z własnym identyfikatorem, który nie może się powtarzać, na rekord, i można je odtworzyć ze źródła. To, co trafia do zewnętrznego modelu, jeśli jest używany, to opis transakcji — nie cały dokument i nie załącznik.
Co się zachowuje i jak długo: Termin przechowywania ustala się według typu danych, nie globalnie, i zapisuje przed uruchomieniem: rekordy biznesowe zgodnie z obowiązkami prawnymi beneficjenta, dzienniki techniczne na krótki okres, pliki pośrednie — nagrania audio, pobrane załączniki — z automatycznym czyszczeniem. System, który nie ma polityki usuwania, po sześciu miesiącach staje się większym ryzykiem niż problem, który rozwiązywał.
Co zostaje u nas po przekazaniu: Po przekazaniu nasz dostęp do Twoich systemów istnieje tylko wtedy, gdy istnieje umowa serwisowa, która tego wymaga, i jest wycofywany, gdy ta się kończy. Kopie robocze z naszych stacji usuwa się na żądanie. To, co zachowujemy w każdym przypadku, to ogólne komponenty, które napisaliśmy i które nie zawierają Twoich danych — i te też deklarujemy od początku, żeby na końcu nie było niespodzianki.

Przykład

System do zapytań dla dwóch portali, które nie mają żadnego API

Sytuacja

Agencja turystyczna potrzebowała, na żądanie, dostępności miejsc i taryf na rejsy czarterowe w portalach B2B dwóch touroperatorów. Portale są zaprojektowane dla ludzkiego oka: logujesz się, szukasz, czytasz tabelę. Nie ma opublikowanego programowego interfejsu, a informacje były ręcznie odczytywane, kilka razy dziennie, przez człowieka.

Co zbudowaliśmy

Napisaliśmy klienta, który uwierzytelnia się programowo i sam odświeża sesję, gdy wygasa, analizator, który zamienia odpowiedzi na obiekty, oraz warstwę identyfikatorów dla lotnisk, gdzie kod składa się z miasta i portu, a niektóre wywołania wymagają dwóch części osobno. Nad tym: komenda wiersza poleceń, która zwraca pełną trasę z dostępnością i ceną, tryb zapytań partiami z pauzami między nimi, aby nie zablokować konta, oraz dwa punkty wejścia JSON na wypadek, gdy inna platforma chce skonsumować wynik. Analizator jest testowany na rzeczywistych odpowiedziach, zapisanych jako fixture w repozytorium, a testy, które rzeczywiście dotykają portali, są oznaczone osobno i nie uruchamiają się domyślnie.

Co z tego wyszło

Pakiet przechodzi w całości: 38 sprawdzeń w 0,52 sekundy, bez dotykania portali. Jedno zapytanie zwraca, w jednej odpowiedzi, dostępność w czterech stanach używanych przez portal oraz taryfę z klasą i bagażem, w wymaganej walucie. Wynik można konsumować z wiersza poleceń, jako JSON, albo przez dwa punkty wejścia HTTP.

Czego nie mówi ten przypadek

Uwierzytelnianie programowe pozostaje szarą strefą względem warunków korzystania z portali i jest to zapisane w README projektu, a nie odkryte po dostarczeniu. Dla intensywnego wolumenu produkcyjnego nasza rekomendacja jest jednoznaczna: należy żądać oficjalnego API od operatorów. System wykonuje zapytania punktowe i robi przerwy między nimi właśnie po to, by nie stał się narzędziem masowego pobierania.

Pytania

O co pytają ludzie, zanim zadzwonią

Dlaczego na tej stronie nie ma żadnej ceny?

Bo nie moglibyśmy jej uczciwie podać. Nakład pracy nad systemem na zamówienie zależy od trzech rzeczy, których nie znamy, zanim nie spojrzymy: ile systemów zewnętrznych trzeba dotknąć i czy któryś ma API, ile reguł biznesowych jest już gdzieś zapisanych, a ile trzeba odkryć od ludzi, oraz kto utrzymuje system po dostarczeniu. Liczba podana przed zobaczeniem systemu to zgadywanka z fakturą. To, co możemy zrobić szybko, to pierwszy etap — odczyt, wyznaczenie granic, zapisanie reguł — który da się poprawnie oszacować i który pozostaje użyteczny, nawet jeśli zatrzymasz się właśnie tam.

Kto jest właścicielem kodu na końcu?

Kod napisany specjalnie dla Ciebie należy do Ciebie, wraz z repozytorium i historią. Biblioteki osób trzecich pozostają pod swoimi licencjami — nie możemy Ci ich przekazać, bo nie są nasze. Nasze komponenty wielokrotnego użytku i nasze istniejące produkty są licencjonowane do używania, nie są przenoszone; jeśli Twoja praca opiera się na jednym z nich, powiemy Ci to w pisemnej ofercie, przed startem, a nie na ostatnim spotkaniu.

Co się dzieje, jeśli chcemy kontynuować z kimś innym?

Przekazanie musi to umożliwiać bez nas, inaczej nie było przekazania. Dlatego dokument uruchomienia jest pisany dla pustej maszyny i nie zakłada niczego z naszej głowy, a testy pozostają w repozytorium, aby kolejny zespół wiedział, co się psuje po zmianie. To, czego nie możemy obiecać, to że złożony system przejmie się bez wysiłku — możemy obiecać tylko, że nie brakuje w nim niczego, co jest potrzebne, aby dało się go przejąć.

Czy mogę zobaczyć system zbudowany przez Was, żeby ocenić jakość?

Częściowo i słusznie jest powiedzieć, gdzie to się kończy. Systemy budowane dla klientów nie są nasze, żeby je pokazywać, a wewnętrzne zawierają rzeczywiste dane biznesowe. To, co możemy zrobić przed Tobą, na ekranie, to coś innego: otwieramy repozytorium, pokazujemy reguły domeny zapisane w tekście, uruchamiamy pakiety testów — 38 w pół sekundy na jednym, 81 w nieco ponad sekundę na innym, 44 na trzecim — i wspólnie czytamy kod, który wykonuje twierdzenie, które poddajesz w wątpliwość. Ta strona jest z kolei własnym systemem, który można oglądać z zewnątrz.

Nasz stary system nie ma API. Da się coś zrobić?

Zazwyczaj tak, ale z deklarowanym ryzykiem. Kolejność jest taka: najpierw pytamy, czy dostawca ma oficjalne API, którego po prostu nie udokumentował publicznie — zdarza się to często. Jeśli nie ma, można pracować przez programowe uwierzytelnianie, dokładnie jak użytkownik, z automatycznie odnawianą sesją; zbudowaliśmy w ten sposób system, który odpytuje dwa portale B2B. Wtedy piszemy jasno, że to szara strefa względem warunków korzystania dostawcy i że przy dużej skali trwałym rozwiązaniem jest poproszenie o oficjalne API. Decyzja pozostaje po Twojej stronie, ale poinformowanej.

Czy używacie sztucznej inteligencji do pisania kodu?

Tak i nie ukrywamy tego. Liczą się zasady, na jakich się to odbywa: każda część pracy kończy się testami, które są uruchamiane, sprawdzeniem typów i przeglądem różnic przed commitowaniem, a ograniczenia są zapisane w repozytorium — bez wdrożeń na produkcję z poziomu pracy, bez zmian w zewnętrznych kontach, adaptery dla dostawców tylko z wariantem symulacji. Kod napisany szybko i niezweryfikowany jest droższy niż kod napisany wolno. To, co się sprzedaje, to szybkość w nudnej części, nie brak weryfikacji.

Co robicie, gdy w połowie okazuje się, że pierwotny pomysł był błędny?

Mówimy o tym. W jednym własnym projekcie inżynieryjnym po ewaluacji doszliśmy do drugiej, całkowicie innej architektury dla tego samego problemu i napisaliśmy ją jako udokumentowaną alternatywę, z bramkami, które trzeba przejść przed każdym zamówieniem, zamiast kontynuować pierwszą tylko dlatego, że była już rozpoczęta. Koszt zmiany kierunku w połowie jest mniejszy niż koszt systemu dostarczonego w złej formie, a różnicę w obu przypadkach płaci odbiorca.

Jak duża może być praca?

Na jednym końcu system z trzema aplikacjami i dwunastoma wspólnymi pakietami w jednym repozytorium, 486 plikami TypeScript, 68 plikami testów i 151 commitami, z relacyjną bazą danych, efemeryczną koordynacją oddzieloną od źródła prawdy i wspólnymi kontraktami między aplikacjami. Na drugim końcu system z jednym procesem i dwudziestoma punktami wejścia, który jest dokładnie tak duży, jak trzeba. Zakres nie jest obietnicą dowolnego rozmiaru — to obserwacja, że pracowaliśmy na obu końcach.

Czy zapewniacie też utrzymanie po wdrożeniu?

Tak, ale jako osobne uzgodnienie, nie jako domysł. System wykonany na zamówienie wymaga aktualizacji bezpieczeństwa, śledzenia zmian u zewnętrznych dostawców i kogoś, kto patrzy w logi. Jeśli wolisz robić to ze swoim zespołem, przekazanie jest zbudowane tak, aby było to możliwe. Jeśli wolisz, żebyśmy robili to my, zapisuje się, co obejmuje, a czego nie — w tym, co znaczy „pilne”, bo bez definicji to słowo nic nie znaczy.

Na czym opierają się powyższe stwierdzenia (15 źródeł)

15 z nich to kod i pliki z naszych repozytoriów. Nie publikujemy ich nazw ani numerów linii: razem, na jednej stronie, opisałoby to zbyt dokładnie, jak zbudowane są systemy, które nie należą tylko do nas. Przechodzimy je razem z Tobą, w repozytorium, na życzenie — weryfikacja pozostaje możliwa, tylko odbywa się w rozmowie.

Jak pracujemy Wszystkie usługi

Co chcesz, żeby działało lepiej?

Opowiedz nam o swoim procesie. Wspólnie ustalimy, co warto zbudować, co da się połączyć i jak sprawdzimy wynik.

Porozmawiajmy