Mobility-as-a-Service łączy pociągi, autobusy, rowery miejskie, hulajnogi i taksówki w jednej aplikacji z jednym biletem i jedną płatnością. Wyjaśniamy, jak działa taka integracja od strony technicznej, jakie dane trzeba połączyć i gdzie leżą realne trudności wdrożenia.
CEO
27 cze 2026
Mobility-as-a-Service, w skrócie MaaS, to model, w którym różne środki transportu - pociąg, autobus, rower miejski, hulajnoga, taksówka czy carsharing - stają się dostępne z poziomu jednej aplikacji. Użytkownik nie kupuje osobnych biletów u osobnych przewoźników, tylko planuje całą trasę od drzwi do drzwi i płaci za nią jednym ruchem. Brzmi jak drobne ułatwienie. W praktyce to zmiana sposobu, w jaki miasta, operatorzy transportu i firmy technologiczne myślą o przemieszczaniu się. Dla pasażera MaaS oznacza mniej aplikacji w telefonie i mniej decyzji po drodze. Dla operatora transportu to nowy kanał sprzedaży biletów i dostęp do danych o popycie, których wcześniej nie miał. Dla firmy budującej taką platformę to przede wszystkim zadanie integracyjne - trzeba połączyć systemy, które nigdy nie były projektowane do współpracy ze sobą.
Jako software house budujemy aplikacje i integracje dla branży transportowej i turystycznej, więc tę samą logikę - łączenie wielu źródeł danych w jedno spójne doświadczenie - widzieliśmy już z bliska.
Aplikacja jednego przewoźnika pokazuje rozkład jego autobusów albo jego rowerów. Mobility-as-a-Service idzie o krok dalej: łączy wielu przewoźników i wiele rodzajów transportu w jedną warstwę planowania i płatności. Użytkownik wpisuje punkt startu i cel, a system sam proponuje kombinację - na przykład dojazd rowerem miejskim na dworzec, pociąg do centrum innego miasta i taksówkę na ostatnim odcinku. Kluczowa różnica leży w tym, kto ponosi odpowiedzialność za całą podróż. W tradycyjnym modelu każdy odcinek trasy to osobna transakcja i osobne ryzyko - spóźniony autobus nie interesuje firmy wypożyczającej hulajnogi. W MaaS platforma pośrednicząca bierze na siebie spięcie tych odcinków w jedną spójną usługę, często z jednym abonamentem miesięcznym zamiast płatności za każdy przejazd osobno.
Warto rozróżnić dwa poziomy integracji, które w praktyce często się mieszają. Pierwszy to integracja informacyjna - jedna aplikacja pokazuje rozkłady i trasy wielu przewoźników, ale bilety wciąż kupuje się osobno. Drugi to integracja transakcyjna, czyli faktyczny zakup i rozliczenie w jednym miejscu. To właśnie ten drugi poziom sprawia najwięcej trudności technicznych i jest tym, co ludzie mają na myśli, mówiąc o pełnym Mobility-as-a-Service.
Zbudowanie takiej aplikacji zaczyna się od odpowiedzi na pytanie, jakie dane w ogóle są dostępne. Duzi operatorzy transportu publicznego zwykle udostępniają dane rozkładowe przez otwarte API, najczęściej w formacie GTFS (General Transit Feed Specification), a dane w czasie rzeczywistym - opóźnienia, zmiany peronów - w formacie GTFS-Realtime. Operatorzy hulajnóg i rowerów miejskich zwykle mają własne interfejsy programistyczne, często zgodne ze standardem GBFS (General Bikeshare Feed Specification), który pokazuje lokalizację i dostępność pojazdów w danym momencie. Problem w tym, że nie każdy przewoźnik udostępnia dane w standardowym formacie. Mniejsze firmy przewozowe, lokalni operatorzy taksówek czy prywatne parkingi często mają własne, niestandardowe API albo w ogóle go nie mają. Wtedy integracja oznacza pisanie dedykowanego łącznika pod konkretnego partnera, uzgadnianie z nim formatu danych i pilnowanie, żeby zmiana po jego stronie nie wywróciła całej aplikacji.
Drugi element to silnik planowania tras, który łączy te wszystkie źródła danych w konkretną propozycję podróży. Musi on brać pod uwagę nie tylko czas przejazdu, ale też czas przesiadki, odległość między przystankiem a punktem odbioru hulajnogi czy dostępność miejsc parkingowych dla roweru. To zadanie obliczeniowe rośnie razem z liczbą partnerów - im więcej środków transportu wchodzi w grę, tym więcej kombinacji trzeba przeanalizować w ułamku sekundy, żeby użytkownik zobaczył wynik od razu po wpisaniu trasy.
Statyczny rozkład jazdy to dopiero połowa historii. Realna wartość dla użytkownika pojawia się wtedy, gdy aplikacja wie, że akurat ten autobus jest spóźniony osiem minut, a najbliższa stacja rowerów miejskich ma tylko jeden wolny rower. Utrzymanie takich danych na bieżąco wymaga stałego połączenia z systemami operatorów, często przez WebSocket albo cykliczne odpytywanie API co kilka sekund, oraz infrastruktury, która wytrzyma skoki ruchu w godzinach szczytu.
Najbardziej widoczna dla użytkownika część MaaS to płatność. Zamiast kupować bilet u każdego przewoźnika osobno, płaci raz - za konkretną podróż albo w formie abonamentu obejmującego określoną liczbę przejazdów czy nielimitowany dostęp do wybranych środków transportu. Od strony technicznej oznacza to integrację z bramką płatności, taką jak Stripe, oraz z systemami biletowymi poszczególnych przewoźników, które muszą wystawić i zwalidować bilet elektroniczny, mimo że transakcję finansową obsłużyła zewnętrzna platforma. Rozliczenie między stronami jest tu osobnym, mniej widocznym zagadnieniem. Platforma MaaS musi wiedzieć, ile z pobranej opłaty należy się kolejowemu przewoźnikowi, ile operatorowi hulajnóg, a ile zostaje jako jej marża. Przy modelu abonamentowym, gdzie użytkownik płaci stałą kwotę miesięcznie niezależnie od liczby przejazdów, ten podział trzeba liczyć na podstawie faktycznego wykorzystania - a to wymaga dokładnego zbierania danych o każdym odcinku podróży i osobnego modułu rozliczeniowego, który działa w tle, poza tym, co widzi pasażer.
Bilet elektroniczny musi też działać offline albo przy słabym zasięgu, bo kontrola biletów w metrze czy w tunelu kolejowym nie może zależeć od stabilnego internetu. W praktyce oznacza to generowanie kodu QR lub biletu w formacie zgodnym z czytnikami danego przewoźnika już w momencie zakupu, z zapisem lokalnym na urządzeniu, a nie dopiero przy okazywaniu go kontrolerowi.
Największą trudnością w budowie Mobility-as-a-Service rzadko jest sam kod. Jest nią liczba stron, z którymi trzeba się dogadać - każdy przewoźnik ma inne API, inny format danych, inny sposób rozliczeń i inne priorytety biznesowe. Negocjacje z operatorami transportu publicznego, prywatnymi firmami przewozowymi i dostawcami mikromobilności zajmują często więcej czasu niż sama integracja techniczna.
Kolejny problem to jakość i spójność danych. Rozkład jazdy w formacie GTFS może być nieaktualny, jeśli operator zapomni go odświeżyć po zmianie trasy. Dane o dostępności hulajnóg potrafią mieć opóźnienie kilku minut względem stanu faktycznego. Platforma MaaS musi radzić sobie z tym, że część informacji, na których opiera swoje rekomendacje, bywa niedokładna - i pokazywać to użytkownikowi w sposób, który nie podważa zaufania do całej aplikacji.
Trzecim wyzwaniem jest utrzymanie integracji w czasie. Partner zmienia wersję swojego API, dodaje nowe pole w odpowiedzi albo wycofuje stare - a platforma MaaS musi to wychwycić, zanim coś przestanie działać w aplikacji użytkownika. Przy kilkunastu czy kilkudziesięciu integracjach jednocześnie potrzeba monitoringu, który sam sygnalizuje awarię konkretnego połączenia, zamiast czekać na zgłoszenie od zdenerwowanego pasażera.
Model MaaS nie ogranicza się do aplikacji miejskich dla mieszkańców. Firmy z rozproszonymi zespołami albo pracownikami dojeżdżającymi z różnych lokalizacji coraz częściej patrzą na tę samą logikę jako sposób na uporządkowanie budżetu transportowego. Zamiast zwracać koszty taksówek, biletów i parkingów osobno, firma może zaoferować pracownikom dostęp do jednej platformy z limitem miesięcznym, która sama rozlicza się z poszczególnymi przewoźnikami. Dla działu HR czy administracji oznacza to jeden raport kosztów zamiast dziesiątek faktur od różnych dostawców. Dla pracownika - jedną aplikację do zaplanowania dojazdu, niezależnie od tego, czy tego dnia wybiera pociąg, carsharing czy rower miejski. Taki model najlepiej sprawdza się w firmach, które mają wielu pracowników przemieszczających się między lokalizacjami albo obsługujących klientów w terenie, gdzie elastyczność środka transportu ma realne znaczenie - to obszar, który najczęściej spotykamy w branży motoryzacyjnej i mobility.
Podobnie jak w klasycznym MaaS, tu też fundamentem jest aplikacja mobilna - to z jej poziomu pracownik zgłasza dojazd, a system w tle rozlicza się z każdym przewoźnikiem osobno.
Poza klasycznym MaaS dla mieszkańców miast ta sama architektura integracyjna sprawdza się w wielu innych kontekstach transportowych. Firmy logistyczne łączą dane z wielu przewoźników, żeby zoptymalizować trasy dostaw - to rozwiązania opisane szerzej przy okazji AI w logistyce. Ten sam mechanizm agregacji danych z wielu źródeł stoi za systemami zarządzania flotą, które łączą informacje z GPS-ów, tachografów i czujników w jeden panel. Biura podróży i touroperatorzy budują z kolei systemy łączące oferty wielu dostawców transportu i noclegów w jedną rezerwację, na wzór opisany w artykule o systemie rezerwacji dla biura podróży.
Podobna logika stoi za systemami zarządzania łańcuchem dostaw, gdzie dane od wielu dostawców trzeba połączyć w jeden spójny obraz. Na tej samej zasadzie działają platformy typu digital freight marketplace, gdzie wielu przewoźników spotyka się na jednej platformie transakcyjnej.
Pełna platforma MaaS obejmująca dziesiątki przewoźników to projekt na lata, ale nie trzeba zaczynać od razu w takiej skali. Sensownym pierwszym krokiem jest wybranie dwóch lub trzech partnerów z dobrze udokumentowanym API - na przykład jednego operatora transportu publicznego i jednego dostawcy mikromobilności - i zbudowanie działającego planera tras oraz płatności właśnie dla nich. Dopiero na tej podstawie dokłada się kolejnych partnerów, co pozwala sprawdzić architekturę integracyjną, zanim skala projektu urośnie.
Od strony technicznej dobrze sprawdza się tu podejście modułowe: osobna warstwa dla pobierania i normalizacji danych od przewoźników, osobna dla silnika planowania tras i osobna dla płatności oraz rozliczeń. Taki podział ułatwia dodawanie nowych integracji bez ryzyka, że zmiana u jednego partnera wywróci działanie całej aplikacji, i wspiera podejście API-first, w którym interfejsy programistyczne projektuje się jako pierwszy, stabilny element systemu, a nie dodatek na końcu.
Warto też od początku zaplanować monitoring integracji i alerty o awariach - przy kilkunastu równoległych połączeniach z zewnętrznymi systemami to nie jest opcja, tylko warunek, żeby aplikacja działała stabilnie na produkcji. Dokumentacja API w standardzie Swagger / OpenAPI po stronie własnej platformy ułatwia z kolei dołączanie kolejnych partnerów, którzy sami będą chcieli się z nią zintegrować. Po stronie samej aplikacji mobilnej dobrym punktem wyjścia bywa React Native, który pozwala utrzymać jedną bazę kodu na iOS i Androida - istotne, gdy platforma MaaS musi rozwijać się równolegle z każdym nowym partnerem transportowym.
Koszt takiego projektu zależy przede wszystkim od liczby integracji i złożoności silnika planowania tras, a punktem odniesienia może być nasz przegląd kosztów tworzenia aplikacji mobilnej. Tego rodzaju projekty prowadzimy w ramach usług mobile development, łącząc pracę nad aplikacją z integracjami po stronie backendu.
Jeśli Twoja firma planuje aplikację łączącą kilku przewoźników albo system rozliczający dojazdy pracownicze, opisz nam ten projekt przez formularz kontaktowy Boring Owl.
FAQ
Blog
Sztuczna inteligencja przestała być w logistyce ciekawostką technologiczną i stała się realnym narzędziem przewagi konkurencyjnej. Algorytmy uczenia maszynowego planują trasy kurierów, sterują robotami w magazynach i z wyprzedzeniem przewidują, czego klienci będą potrzebować za tydzień, miesiąc czy kwartał.
API-first to innowacyjna strategia w sferze IT, zdobywająca coraz większą popularność. Stawiając na nią, projektanci systemów IT potrafią skuteczniej reagować na dynamicznie zmieniające się potrzeby rynku. Czym więc jest API-first i dlaczego zdobywa coraz większą popularność w biznesie IT?
System rezerwacyjny to dziś jedno z kluczowych narzędzi, które usprawnia pracę firm działających w modelu usługowym. Umożliwia klientom szybkie i wygodne umawianie wizyt online, a przedsiębiorcom pozwala automatyzować wiele procesów, które wcześniej wymagały ręcznej obsługi. Dzięki nowoczesnym rozwiązaniom rezerwacja terminu staje się prostsza, bardziej przejrzysta i dostępna o każdej porze.
W dobie globalizacji i rosnącej presji na efektywność, logistyka staje się jednym z kluczowych obszarów transformacji cyfrowej. Tradycyjne metody organizacji transportu przestają wystarczać w świecie, który wymaga szybkości, elastyczności i pełnej przejrzystości działań. W odpowiedzi na te wyzwania powstały Digital Freight Marketplaces (DFM) – cyfrowe platformy, które rewolucjonizują sposób, w jaki załadowcy, przewoźnicy i operatorzy logistyczni współpracują.
Zarządzanie flotą pojazdów to wyzwanie, które wymaga precyzyjnej organizacji, kontroli kosztów i dbałości o bezpieczeństwo. Wraz z rozwojem technologii coraz więcej firm decyduje się na wdrożenie specjalistycznych systemów, które automatyzują i usprawniają codzienne procesy. Fleet Management Software (FMS) to rozwiązanie, które pozwala monitorować pojazdy w czasie rzeczywistym, ale także optymalizować ich wykorzystanie i wspierać decyzje strategiczne.
Tworzenie aplikacji mobilnej to jeden z najczęstszych kroków firm i startupów. Jednak już na etapie planowania pojawia się kluczowe pytanie: ile to właściwie kosztuje? Odpowiedź nie jest prosta, bo cena zależy od wielu czynników – od rodzaju aplikacji, przez technologię, aż po zespół, który ją tworzy. W tym artykule przyjrzymy się szczegółowo wszystkim elementom, które wpływają na budżet projektu mobilnego.
