Jak w sześć tygodni zbudowaliśmy launcher Web3 po przejęciu projektu

W marcu 2023 firma rozwijająca platformę metaverse zgłosiła się do nas z pilnym problemem. Za sześć tygodni mieli współorganizować duże wydarzenie online z globalnym partnerem, które miało zaprezentować ich technologię tysiącom użytkowników. Ich zespół nie był jednak w stanie dostarczyć działającego desktopowego launchera.

Klient potrzebował zespołu, który szybko przejmie projekt, podejmie jasne decyzje i opracuje rozwiązanie mimo presji czasu. Współpraca z poprzednim vendorem trwała miesiącami, ale kod nie działał i nie rokował poprawy. Termin wydarzenia był stały i nienegocjowalny. Trzeba było działać natychmiast.

W sześć tygodni musieliśmy stworzyć od zera wieloplatformowy launcher desktopowy, który:

• autoryzuje użytkowników przez portfel kryptowalutowy,
• pobiera i uruchamia silnik gry,
• pozwala zmieniać nick i avatar,
• działa niezawodnie na Windows i macOS.

Technologie

• Electron (Chromium + Node.js) – baza aplikacji desktopowej
• React + React Boilerplate – warstwa UI
• Web3 wallet integration – logowanie przez rozszerzenie portfela
• Download manager + extraction – obsługa dużych buildów gry
• Child-process game launcher – uruchamianie gry z prawidłowymi uprawnieniami audio/video
• Code signing – Apple Developer ID (macOS) i Windows Authenticode z fizycznym kluczem
• Kubernetes – hosting silnika metaverse, IaC, multi‑region

Wyzwania

Presja czasu

Sześć tygodni to bardzo mało na stworzenie produkcyjnej aplikacji. Przeszliśmy na sprinty tygodniowe, żeby szybciej reagować. Termin był sztywny, wydarzenie zapowiedziane, bilety sprzedane. Nie chodziło tylko o oprogramowanie, ale też o reputację klienta.

W 2023 AI do pisania kodu dopiero startowało i nie nadawało się do pracy produkcyjnej, więc nie mogliśmy liczyć na żadne skróty.

Dotychczasowy launcher był nienaprawialny

Po przejrzeniu repozytorium poprzedniego vendora odkryliśmy:

• spory dług techniczny,
• funkcje zaczęte, ale niedziałające,
• makiety wymieszane z kodem produkcyjnym,
• architekturę trudną do zrozumienia.

Dodatkowo launcher był tworzony na potrzeby stałego wirtualnego świata, a nie jednorazowego wydarzenia, więc sama koncepcja projektu nie pasowała do wymagań.

Naprawa cudzego kodu bywa szybsza, ale tylko jeśli fundamenty są solidne. Tu nie były. Do tego klient ostrzegł nas, że poprzedni vendor praktycznie nie współpracował. Przy takim terminie brak transparentności oznaczałby katastrofę.

Zdecydowaliśmy więc: budujemy od zera.

Złożone wymagania techniczne

Launcher musiał obsłużyć:

• logowanie przez rozszerzenie portfela,
• pobieranie dużych buildów gry,
• szybkie i stabilne rozpakowywanie,
• uruchamianie gry jako procesu podrzędnego,
• przekazywanie uprawnień mikrofonu i kamery,
• podpisywanie kodu, żeby systemy operacyjne ufały aplikacji.

Electron był dla nas nowością. Rozszerzenia przeglądarkowe działają w nim inaczej niż w Chrome, dlatego musieliśmy samodzielnie zarządzać ich cyklem życia. Podpisywanie kodu na Windows wymagało fizycznego klucza, więc buildy były podpisywane ręcznie przez zespół pracujący zdalnie.

Silnik gry uruchamiany jako proces podrzędny oznaczał kolejne komplikacje. Uprawnienia audio/video musiały być przekazywane bezbłędnie, bo inaczej kluczowe funkcje przestałyby działać.

Komunikacja i koordynacja

Po stronie klienta pracował zespół techniczny, PM‑owie, artyści 3D i game dev. Musieliśmy szybko doprecyzować wymagania, sygnalizować ryzyka i pokazywać regularny postęp. Klient miał za sobą trudną współpracę z innym dostawcą, więc odbudowanie zaufania było równie istotne jak sam development.

Transparencja budowała zaufanie.

Rozwiązania

Strategiczna decyzja: budujemy od zera

Nowy launcher oznaczał czystą architekturę, technologie które znamy i pełną kontrolę nad kodem. Wybraliśmy Electron, bo sprawdzają go rozwiązania takie jak Discord czy VS Code. UI postawiliśmy na React Boilerplate.

Ryzyko czasu było realne, ale wiedzieliśmy, że szybciej zbudujemy coś własnego niż będziemy walczyć z cudzym chaosem.

Bezwzględna priorytetyzacja

Musieliśmy odejść od pokusy „budowania wszystkiego”. Najważniejsza była ścieżka użytkownika:

1. Pobierz launcher
2. Zaloguj się portfelem
3. Pobierz build gry
4. Uruchom grę
5. Dołącz do wydarzenia

Wszystko poza tym było dodatkiem.

Przykłady uproszczeń:

• hardkodowanie wersji rozszerzenia portfela,
• brak optymalizacji procesu ekstrakcji – działał, więc zostawiliśmy,
• ręczne testy zamiast automatycznych,
• brak blokady uruchamiania wielu instancji gry.

Zasada była prosta: działające jest lepsze niż idealne.

Implementacja techniczna

Budowaliśmy launcher warstwowo.

Electron dzieli aplikację na dwie części:

• renderer – UI,
• main – operacje systemowe.

To rozdzielenie pozwoliło nam utrzymać porządek i jasną logikę projektu.

Najważniejsze elementy:

• integracja logowania z portfelem Web3,
• pobieranie buildów z obsługą błędów i paskiem postępu,
• rozpakowywanie archiwów z czytelnymi komunikatami,
• uruchamianie gry jako procesu podrzędnego, w tym uprawnienia audio/video i obsługa cyklu życia procesu.

Testowaliśmy wszystko na bieżąco, dzięki czemu unikaliśmy późnych niespodzianek.

Współpraca z klientem

Zespół klienta był zaangażowany i decyzyjny, ale nie wchodził nam w drogę. Pomagał, kiedy było trzeba i reagował na bieżąco. Regularne prezentacje i szybkie decyzje pozwalały utrzymać tempo. Klient widział postęp i miał pewność, że projekt idzie w dobrym kierunku.

Koordynacja zespołu

Działaliśmy szybko, bo byliśmy świetnie skoordynowani. Dedykowany PM dbał o komunikację z klientem, a developerzy mogli skupić się na pracy. Wcześnie zebraliśmy informacje o zależnościach: API, assetach, hostingach buildów. Sprinty tygodniowe utrzymywały wysoką dynamikę prac.

Wszyscy wiedzieliśmy, jak napięty jest harmonogram, więc nasze decyzje były szybkie i pragmatyczne.

Podsumowanie

Dostarczyliśmy launcher na czas. Wydarzenie przebiegło bez problemów. Tysiące użytkowników pobrało launcher, zalogowało się portfelem i dołączyło do eventu.

Co ważne, launcher zbudowany w sześć tygodni stał się fundamentem głównego produktu klienta. Gdy zespół klienta przebudowywał własny launcher, zaczęli od naszego kodu. Mimo presji czasu aplikacja była na tyle stabilna i czysta, że posłużyła jako baza do długoterminowego rozwoju.

Współpraca trwała ponad dwa lata. Zbudowane zaufanie przełożyło się na stałą relację i kolejne projekty.