Travel platform: API, traveller app and back-office

The context

A tour operator needed a platform covering its whole chain: preparing trips on the team side, distributing them to travellers, and providing the necessary documents on the ground. Three audiences, three interfaces, one source of truth.

The challenge

The hard part of a travel application is obvious the moment you think about it, and forgotten in nine projects out of ten: the traveller has no network exactly when they need it.

They check their itinerary on a plane, look for their ticket in a crowded station concourse, verify an address abroad with no data plan. An application that assumes a permanent connection is an application that fails precisely when it matters.

A second constraint: the traveller must not have to create an account. An access code should be enough — without a random code granting access to somebody else’s data.

What we did

• A Django REST API as the single business foundation, exposing trips, participants and their associated documents.
• A Flutter traveller application, fully usable offline. Data is serialised and stored locally: the itinerary, practical information and documents stay available without a network, and resynchronise as soon as a connection returns.
• Code-based access with no account creation, backed by security rules written so that reading a trip requires the right code — and only that one. The convenience of frictionless access, without opening the door to other travellers’ data.
• A Flutter back-office for internal teams, with authentication separate from the travellers’.
• PDF ticket and document generation with barcodes, produced server-side so they render identically whatever device displays or prints them.
• Push notifications to travellers, and deployment on Apache infrastructure with automated certificates.

The outcome

The platform is live and continues to evolve. The API and back-office have been shipping regularly since going into production.

The decision that mattered most was treating offline as a day-one requirement rather than a later improvement. That choice shapes local storage, synchronisation and the data model — near impossible to retrofit, and invisible when it is done well.