Praveen Neppalli Naga, CTO Ubera, pojawi się 30 kwietnia na konferencji StrictlyVC w San Francisco, żeby opowiedzieć o tym, jak buduje się zespoły inżynierskie w firmie obsługującej miliardy przejazdów rocznie. Dla polskich przedsiębiorców brzmi to jak temat z innej planety - bo co wspólnego ma firma z 30 osobami w Warszawie z gigantem zatrudniającym dziesiątki tysięcy ludzi w 70 krajach?
Okazuje się, że całkiem sporo. Wzorce, które Uber wypracował przez 15 lat skalowania, są dziś dostępne dla każdej firmy mającej dostęp do GitHuba, AWS i Claude'a. Polskie firmy często czekają z porządną inżynierią aż "urosną" - i to jest błąd, który kosztuje miesiące, a czasem lata straconego czasu.
W tym artykule pokażę, czego polskie małe i średnie firmy mogą się nauczyć od inżynierów big-tech. Nie chodzi o kopiowanie - chodzi o wybranie tych zasad, które działają niezależnie od skali, i wdrożenie ich zanim chaos w kodzie zacznie blokować rozwój biznesu.
Inżynieria nie czeka, aż będziesz duży
Klasyczny błąd: "Najpierw zróbmy coś, co działa, potem to przepiszemy porządnie." W teorii brzmi rozsądnie. W praktyce ten "porządny refaktor" nigdy nie nadchodzi, bo gdy firma rośnie, produkt staje się coraz droższy w utrzymaniu, a każda nowa funkcja wymaga obejścia trzech wcześniejszych obejść.
Naga w wywiadach wielokrotnie podkreślał, że Uber popełnił ten błąd we wczesnej fazie. Pierwsze monolityczne aplikacje musiały zostać rozbite na mikrousługi pod presją skali, co kosztowało zespoły lata pracy. Lekcja: niektóre decyzje architektoniczne podjęte na początku determinują, jak szybko firma może się rozwijać przez kolejną dekadę.
Co to oznacza dla polskiej firmy zatrudniającej 5-50 osób? Po pierwsze, zacznij od obserwowalności. Każdy skrypt, każda automatyzacja, każda integracja powinna mieć logi w jednym miejscu i alerty na błędy. Narzędzia takie jak Sentry (darmowy do 5000 zdarzeń miesięcznie), Datadog czy nawet zwykły Grafana Cloud dają to bez konfiguracji infrastruktury. Bez logów debugowanie produkcyjnego problemu zajmuje godziny zamiast minut.
Po drugie, kontrola wersji wszystkiego - nie tylko kodu. Pliki konfiguracyjne, skrypty SQL, dokumenty procesowe, a nawet prompty do modeli AI powinny być w Git. To jedna z lekcji, którą polskie firmy ignorują najczęściej. "To tylko Excel z marżami" - okej, ale gdy ktoś go przypadkowo nadpisze, tracisz tydzień pracy.
Małe iteracje zamiast wielkich projektów
Big-tech od dawna pracuje w cyklach tygodniowych lub krótszych. Każda zmiana wchodzi na produkcję małymi porcjami, jest mierzona i albo zostaje, albo wraca. Polskie firmy często działają odwrotnie: trzymiesięczny projekt, na końcu którego okazuje się, że klienci chcieli czegoś innego.
Powód jest prosty: małe iteracje wymagają dyscypliny w testowaniu i wdrażaniu. Jeśli każdy deploy zajmuje cztery godziny i wymaga obecności trzech osób, robisz go raz w miesiącu. Jeśli wystarczy git push i automatyczny pipeline w GitHub Actions, robisz go pięć razy dziennie. Różnica w tempie uczenia się produktu jest dramatyczna.
Konkretny przykład z polskiego rynku: firma e-commerce z Krakowa, która automatyzowała wycenę przesyłek. Pierwsza wersja zajęła trzy miesiące, druga dwa tygodnie, a trzecia trzy dni. Nie dlatego, że programiści stali się szybsi - dlatego, że zbudowali infrastrukturę pozwalającą na szybkie iteracje. Każda kolejna zmiana kosztowała mniej, bo wcześniejsze inwestycje w testy i pipeline'y się zwracały.
Dane jako fundament decyzji, nie ozdoba
W Uberze każda funkcja produktu ma swoje metryki. Nie raporty kwartalne - dashboardy aktualizujące się w czasie rzeczywistym. Gdy ktoś proponuje zmianę algorytmu wyceny przejazdu, dyskusja nie zaczyna się od "myślę że...", tylko od "oto wpływ tej zmiany na konwersję, czas oczekiwania i NPS przewozu". To nie jest kwestia kultury - to kwestia infrastruktury, która sprawia, że odpowiedź na takie pytanie jest dostępna w pięć minut, nie w pięć dni.
Polska firma sprzedająca subskrypcje przez internet nie potrzebuje data warehouse jak Snowflake za kilka tysięcy dolarów miesięcznie. Wystarczy darmowy BigQuery (1 TB zapytań miesięcznie gratis), Metabase open source jako interfejs i kilka prostych dashboardów: ile leadów przyszło, ile się zarejestrowało, ile zapłaciło, ile odeszło po miesiącu. To dane, które każda firma SaaS powinna mieć pod ręką, a połowa polskich startupów wciąż liczy je ręcznie w Excelu raz na kwartał.
Trzy konkretne metryki, które warto mieć w dashboardzie od pierwszego dnia: czas od rejestracji do pierwszego kluczowego działania użytkownika (aktywacja), procent użytkowników aktywnych w ostatnich 30 dniach (retencja) oraz średni przychód na klienta. Bez tych liczb każda dyskusja o kierunku produktu jest oparta na intuicji.
AI jako mnożnik produktywności inżynieryjnej
Ostatnia lekcja, która dla polskich firm jest największą szansą: AI w 2026 roku zniwelowało dystans między małym zespołem a korporacją. Narzędzia takie jak Claude Code, Cursor czy GitHub Copilot pozwalają jednemu programiście dostarczyć tyle kodu, ile dwa lata temu robiło trzech. To znaczy, że firma z trzyosobowym zespołem inżynierskim może realnie konkurować jakością z dziesięcioosobowymi zespołami sprzed ery LLM.
Z mojego doświadczenia konsultingowego: polskie firmy które wdrożyły Claude Code lub równoważne narzędzia w obiegu pracy programistów, raportują skrócenie czasu od zgłoszenia bugu do poprawki o 40-60%. Nie jest to magia - to po prostu mniej tarcia w codziennych mikrozadaniach: pisanie testów, refaktoryzacja, dokumentacja, wyjaśnianie nieznanego kodu.
Ograniczenie, o którym warto wiedzieć: AI nie zastąpi sensownej architektury. Jeśli kod jest chaotyczny, model będzie generował kolejny chaotyczny kod, tylko szybciej. Inżynieria, dyscyplina, testy - to wszystko nadal musi być zrobione przez ludzi. AI jest mnożnikiem, nie substytutem.
Podsumowanie: zacznij dziś, nie za rok
Lekcje z big-tech dla polskich firm sprowadzają się do jednej zasady: nie czekaj, aż urośniesz, żeby wprowadzić porządną inżynierię. Decyzje techniczne podjęte przy 5 osobach determinują, jak wygląda firma przy 50. Obserwowalność, kontrola wersji, krótkie iteracje, dane w czasie rzeczywistym i AI w obiegu pracy - to nie są luksusy dla korporacji, tylko fundament konkurencyjności w 2026 roku.
Konkretna rekomendacja na ten tydzień: wybierz jedną z tych pięciu zasad i wdróż ją w swojej firmie. Nie wszystkie naraz - jedną. Za miesiąc zobaczysz różnicę, za pół roku konkurencja będzie się zastanawiać, jak nadążasz. Inżynieria to nie kwestia rozmiaru - to kwestia decyzji.
Źródło: Uber CTO Praveen Neppalli Naga joins StrictlyVC SF lineup