Zbudowałem platformę turystyczną z integracją MerlinX i GIATA — a firma klienta upadła tuż przed startem

Historia z mojej praktyki: strona, która nigdy nie wystartowała

Nie każdy projekt kończy się happy endem, w którym klient wchodzi na nową stronę i zaczyna zbierać pierwsze zapytania. Czasem 80% pracy jest gotowe, a mimo to strona nigdy nie ujrzy światła dziennego — i to zupełnie nie z winy wykonawcy ani klienta. Opowiem Ci o jednym z takich projektów, bo wyciągnąłem z niego lekcję, która dziś chroni zarówno mnie, jak i moich klientów.

Projekt: platforma turystyczna z integracją MerlinX i GIATA

To nie była prosta wizytówka. Klient prowadził biuro podróży, a platforma miała korzystać z systemu rezerwacyjnego MerlinX — jednego z popularniejszych systemów rezerwacyjnych w polskiej branży turystycznej, agregującego oferty wielu touroperatorów (m.in. takich jak Itaka i inni). Dzięki temu, mimo że klientem było pojedyncze biuro podróży, zakres danych po stronie integracji był ogromny — samo MerlinX dawało dostęp do około 20 tysięcy hoteli i 300-400 tysięcy ofert. Do tego dochodziła baza treści hotelowych GIATA (opisy, zdjęcia, oceny obiektów wykorzystywane przez większość touroperatorów) oraz szereg dodatkowych API, które trzeba było spiąć w jedną spójną całość — wyszukiwarkę ofert, dostępność, ceny w czasie rzeczywistym, proces rezerwacji.

To były miesiące pracy: architektura integracji, mapowanie danych między systemami, obsługa błędów gdy jedno z API akurat nie odpowiadało, optymalizacja wydajności przy tak dużym wolumenie danych. Dokładnie ten typ projektu, który pokazuje różnicę między „postawieniem strony” a zbudowaniem działającego systemu.

Największe wyzwanie: limity API i ceny, które zmieniają się w czasie rzeczywistym

Największym problemem technicznym w tym projekcie okazały się limity zapytań do API MerlinX. Po ich przekroczeniu każde kolejne zapytanie stawało się dodatkowo płatne — przy takiej skali ofert (300-400 tys.) trzeba było więc bardzo rozsądnie zarządzać tym, kiedy i jak często faktycznie odpytujemy zewnętrzne API, zamiast robić to przy każdym wejściu użytkownika.

Rozwiązaniem był Redis jako warstwa cache w pamięci, trzymająca wyniki zapytań przez 15 minut. To kompromis między dwoma sprzecznymi wymaganiami: z jednej strony ceny w ofertach turystycznych zmieniają się dynamicznie i nie można ich cachować zbyt długo, z drugiej — każde zbędne zapytanie do MerlinX kosztowało realne pieniądze po przekroczeniu limitu. 15 minut okazało się rozsądnym środkiem między aktualnością danych a kosztami API.

Był jeszcze jeden istotny detal związany z płatnościami: skoro ceny cachowane były nawet na kilkanaście minut, a klient mógł dokończyć płatność później niż w momencie wyszukania oferty, trzeba było zabezpieczyć się przed rozjazdem ceny. Dlatego ostateczna cena była pobierana na nowo bezpośrednio w momencie płatności, a nie brana z cache — żeby mieć pewność, że klient płaci dokładnie tyle, ile faktycznie kosztowała oferta w danej chwili, niezależnie od tego, ile czasu minęło od jej wyszukania.

Co poszło nie tak

Nic, jeśli chodzi o samą realizację. W momencie, gdy projekt się zatrzymał, etapy integracji były już finalne, a płatności podłączone — do startu zostały praktycznie same testy przed uruchomieniem. Problem pojawił się z zupełnie innej strony — firma klienta upadła, zanim zdążyliśmy wystartować. To się po prostu zdarza w biznesie, szczególnie w branżach mocno zależnych od sezonowości i marż, jak turystyka. Nie miało to nic wspólnego z jakością pracy ani z relacją z klientem — to było zdarzenie zewnętrzne, na które żadna ze stron nie miała wpływu.

Dlaczego mimo wszystko wyszedłem na tym w porządku

Tu dochodzimy do sedna tej historii. Od dawna pracuję na zaliczkach i kamieniach milowych — nie czekam z całą płatnością do samego końca projektu, tylko rozbijam ją na etapy, płatne po realizacji konkretnego zakresu. Dzięki temu, mimo że strona ostatecznie nigdy nie wystartowała, byłem wynagrodzony za każdy etap pracy, który faktycznie wykonałem.

To nie jest zabezpieczenie tylko dla mnie jako freelancera — to zabezpiecza też klienta. Gdyby coś poszło nie tak z mojej strony w trakcie realizacji, klient też nie traciłby całej kwoty za niedokończoną pracę. Kamienie milowe to uczciwa struktura dla obu stron, nie tylko ochrona wykonawcy.

Co zostało z tego projektu

Sama integracja MerlinX + GIATA nigdy nie ujrzała światła dziennego jako produkt dla tego konkretnego klienta — to były rozwiązania szyte dokładnie pod jego model biznesowy i katalog ofert, więc nie nadawały się do prostego przeniesienia gdzie indziej. Zostało za to coś ważniejszego: doświadczenie w łączeniu skomplikowanych, wielu systemów API w jeden spójny, wydajny produkt — czego doświadczenie zwykła strona internetowa dla firmy zwykle nie wymaga, ale duże projekty z realną logiką biznesową (rezerwacje, systemy magazynowe, integracje z ERP) — jak najbardziej.

Lekcja dla Ciebie, jeśli zlecasz budowę strony lub systemu

Jeśli planujesz większy projekt — sklep, system rezerwacyjny, integrację z zewnętrznymi API — zwróć uwagę, czy wykonawca proponuje płatność w kamieniach milowych, a nie tylko „50% teraz, 50% na koniec”. To chroni Cię dokładnie tak samo jak chroni wykonawcę: płacisz za to, co faktycznie powstało, etap po etapie, a nie za obietnicę, że coś kiedyś powstanie w całości.