Plataforma de viajes: API, app y back-office

El contexto

Un operador de viajes necesitaba una plataforma que cubriera toda su cadena: preparar las estancias del lado del equipo, distribuirlas a los viajeros y proporcionar sobre el terreno los documentos necesarios. Tres públicos, tres interfaces, una sola fuente de verdad.

El reto

El punto difícil de una aplicación de viajes es evidente en cuanto se piensa en ello, y se olvida en nueve proyectos de cada diez: el viajero no tiene cobertura justo cuando la necesita.

Consulta su programa en un avión, busca su billete en un vestíbulo de estación saturado, verifica una dirección en el extranjero sin tarifa de datos. Una aplicación que presupone conexión permanente es una aplicación que falla exactamente en el momento que cuenta.

Segunda restricción: el viajero no debe tener que crear una cuenta. Un código de acceso debe bastar — sin que un código al azar dé acceso a los datos de otra persona.

Lo que hicimos

• Una API Django REST como base de negocio única, que expone las estancias, los participantes y los documentos asociados.
• Una aplicación del viajero en Flutter, totalmente utilizable sin conexión. Los datos se serializan y se conservan localmente: el programa, la información práctica y los documentos siguen consultables sin red, y se resincronizan en cuanto vuelve la conexión.
• Un acceso por código, sin creación de cuenta, con reglas de seguridad escritas para que la lectura de una estancia exija el código correcto — y solo ese. La comodidad de un acceso sin fricción, sin abrir la puerta a los datos de los demás viajeros.
• Un back-office en Flutter para los equipos internos, con autenticación distinta de la de los viajeros.
• Generación de billetes y documentos PDF con códigos de barras, producidos del lado del servidor para que sean idénticos en cualquier dispositivo que los muestre o los imprima.
• Notificaciones push hacia los viajeros y despliegue sobre una infraestructura Apache con certificados automatizados.

El resultado

La plataforma está en servicio y sigue evolucionando. La API y el back-office reciben entregas regulares desde la puesta en producción.

La decisión que más pesó fue tratar el modo sin conexión como una exigencia de partida, no como una mejora posterior. Es una elección que estructura el almacenamiento local, la sincronización y el modelo de datos — casi imposible de recuperar después, e invisible cuando está bien hecha.