Build a Mobility as a Service Platform That Cities Actually Use

Bring transport, tickets, and payment into a mobility as a service platform, built for real-world load.

What a Mobility as a Service Platform Needs to Do

one journey

Bus, taxi, parking, bikes, and car-sharing need to come together in one app, with a single trip planner returning one result. Booking and ticketing sit in the same flow as payment, so a rider buys one ticket for the whole trip. Vehicle positions and arrival times update live, pulled from real data feeds.

Most operators already have a ticketing system, a payments provider, and a live vehicle feed, though none of them were built to talk to each other. Each new region adds its own operator and its own configuration on top. When the pieces do not line up, it shows up as tickets that will not validate and arrival times that cannot be trusted.

Core Capabilities Qulix Builds

capabilities

Qulix builds the mobile side of multimodal mobility platforms. Our teams cover this ecosystem end to end, from the passenger-facing iOS and Android applications to the integrations with external transport and payment services, plus web support and QA.

Multimodal trip planning
Trip planning can cover every transport mode available in a region: bus, taxi, parking, bikes and car-sharing, with filtering based on rider needs. Weather, air quality, and health data can also be layered into the route.
Payment integration
Ticket purchase and card top-up run through Stripe, so a payment still goes through when everyone is buying a ticket at once.
Non-authorised mode
A rider checking a route or buying a single ticket does not need an account first.
Trip rating and feedback
Trip rating can sit inside the rider journey, so operators collect feedback without sending riders to a separate system.
Regional payment support
Payment methods can be adapted to each region's own card standards, such as North America's own card functionality.
Filtering and trip options
Riders can narrow results by mode, cost, or time.
Analytics integration
Product analytics run through Matomo, covering route selection, purchases, and use of key features.
Accessibility
Accessibility features for people with disabilities can be built into the journey from the start, as a working part of how the trip is planned and booked.

A single MaaS API can expose all of this, so operators don't need to maintain a separate integration for every mode. These capabilities are easy to describe and hard to keep running together under real commuter load. It is also the kind of work behind Qulix's wider Transportation Mobile App Development.

DISCUSS THE PROJECT

Why This Is Technically Hard

difficulties

A MaaS platform faces its real test on the first busy morning commute, when riders across a city open the app within the same few minutes. Four things have to hold at once, every working day.

Real-time data

A vehicle position that is a few seconds old shows the rider a route that is already wrong. Positions and delays update in near real time, and the app flags any source that goes quiet.

Many sources, one interface

Transport operators, payment providers, analytics and parking systems each arrive with their own data format and uptime record. The rider sees one consistent interface on top of all of them.

Peak load

Commute peaks push concurrent users up sharply within minutes. The app stays responsive under that load every working day.

Failure isolation

If a payment provider or a vehicle feed goes down, the rest of the platform keeps working.

Below is how this plays out on a MaaS platform Qulix has supported in production since 2022.

Case Study: A Multi-Region MaaS Platform in Production Since 2022

case study

Since 2022, Qulix has run the mobile side of a Mobility as a Service platform for public transport passengers across regions in France and Canada.

The product is an integrated mobility platform spanning passenger-facing iOS and Android applications, a web counterpart, and back-office systems used by the client's own representatives. Qulix's scope covers the iOS and Android apps end-to-end, including QA and product analytics through Firebase and Matomo.

4.3

Average iOS rating from roughly 4,800 reviews, ranging from 4.0 to 4.5 across regions.

100,000+

Downloads on one regional Android app.

140MB → 75MB

Regional Android app size after optimisation.

4 years

Continuous work on the same product, with the team growing to nine engineers across iOS, Android and QA.

One app for every region

Mobility settings for each region come from the client's back office. The same iOS and Android apps run correctly across every regional setup, with no separate build per region.

Live data the rider can trust

Vehicle positions, delays, and parking availability arrive from external systems of varying quality and latency. When a source goes quiet or returns stale data, the app stays responsive and tells the rider.

Tickets that open underground

A passenger who has already bought a ticket can open it and see the route even without connection.

Payments minutes before departure

Riders buy real tickets for real money, often just before a train or bus leaves. Booking, ticketing, and payment data handling sit within Qulix's scope, where a failure would reach the operator as a complaint within minutes.

How Qulix Approaches a MaaS Build

approach

Qulix approaches building MaaS software the same way for every engagement: understand what already exists, then build around it. Most of the systems a new build needs to work with are already live, and the build has to respect that from the first week.

Integration audit

The integration audit comes first: how the mobile app meets the backend and the external systems behind it, the transport operators, payment providers and live vehicle feeds a platform like this depends on.

Phased delivery

Work is scoped and delivered region by region and integration by integration, with engineers embedded in the client's own process from day one.

Ongoing support

Support continues for as long as the platform is live, covering load and uptime as usage grows, alongside new features and new regions.

FAQ

questions

A MaaS platform, sometimes called transportation as a service, includes multimodal trip planning, in-app payment and ticketing, real-time transport data, and accessibility features, unified in a single interface across bus, taxi, parking, bikes and car-sharing.

An existing transport app can be extended into a MaaS platform by adding multimodal trip planning, payment integration, and real-time data feeds incrementally, turning it into a mobility as a service app without being rebuilt from scratch. The existing architecture and available APIs should be assessed first to determine the scope of the extension.

MaaS platforms are difficult to build because they require several third-party integrations to run concurrently, near-instant updates on vehicle position, and stable performance under peak commuter load.

Timelines vary with scope, existing systems, and the number of regions involved. A single-region pilot moves faster than a multi-operator rollout across several countries. Qulix scopes the timeline during the first few weeks of a project, once the required integrations and

Whether you are a transport authority, an operator, or a mobility as a service company, building a MaaS platform means solving for real-time data, concurrent integrations, and peak load.

TALK TO US ABOUT YOUR MAAS PROJECT

Contacts

get in touch

We’d love to hear from you!

Tell us about your project or the challenge you have, and we’ll get back to you soon.

Prefer direct contact?

E-mail us at request@qulix.com