Una interfaz simple, reglas que se sostienen

Un lugar público. Una duración elegida. Dos participantes. La aplicación permite proponer una actividad cercana o unirse a ella, sin recorrer fotos ni biografías. Detrás de este formato deliberadamente reducido, construimos un producto que debe gestionar una plaza única, horarios, conexiones interrumpidas e información que no debe ser visible para todos.

El contexto

Tomar un café, caminar, visitar una exposición: el punto de partida es una actividad y una disponibilidad comunes. Una persona propone, otra se une. Se conocen en el lugar.

El producto lo diseña y desarrolla Scopes, desde Montpellier. El trabajo abarca el diseño del recorrido, la aplicación iOS y Android, los servicios de negocio, la administración y el sitio de presentación. La restricción consiste en mantener la experiencia legible mientras se tratan las situaciones menos visibles: dos personas reservan en el mismo instante, una respuesta de red llega después de una desconexión, un encuentro expira mientras una petición espera.

Estas situaciones determinan la arquitectura tanto como las pantallas.

Modelar el recorrido antes de multiplicar las pantallas

El ciclo de una propuesta se describe con estados y transiciones explícitos: publicación, reserva, llegada, cancelación, expiración. Las reglas se agrupan en un módulo TypeScript independiente de la red y de la base de datos. Recibe la identidad del actor y la hora proporcionada por el servidor, y decide entonces si la acción es posible.

Esta separación permite verificar una regla con precisión de milisegundos sin lanzar la aplicación. Evita también que una pantalla, una ruta HTTP y un tratamiento automático interpreten de forma distinta la misma situación.

La API se apoya en Fastify y PostgreSQL. La elección de un monolito modular mantiene las operaciones de negocio en una misma transacción y limita el número de servicios que explotar. Los contratos de validación se comparten con los clientes; los accesos SQL permanecen en el servidor.

Garantizar la plaza única

Si dos personas pulsan «Unirse» simultáneamente, solo una debe obtener la plaza. La decisión se toma en una transacción PostgreSQL que bloquea la propuesta afectada. La segunda petición relee, por tanto, un estado ya reservado.

La hora se verifica después de obtener el bloqueo: esperar una transacción no debe permitir unirse a una actividad cuyo inicio ha pasado entre tanto.

La creación trata también las reanudaciones de red. Cada petición lleva una clave que permite reconocer su repetición. Si la primera creación tuvo éxito pero su respuesta se perdió, el nuevo intento recupera la misma propuesta. No publica una segunda actividad. Estos comportamientos se prueban con transacciones concurrentes en una base PostgreSQL real.

Buscar alrededor, a petición

La aplicación usa React Native y Expo, con un mapa nativo como punto de entrada. La persona elige una zona, un radio de búsqueda y restricciones de tiempo y duración. PostGIS realiza la búsqueda geográfica en el servidor, con distancias expresadas en metros.

La localización se solicita mediante una acción explícita. También puede elegirse una zona manualmente. Desplazar el mapa no desencadena sistemáticamente una nueva petición: el usuario confirma la búsqueda en la zona mostrada. El recorrido no necesita seguir sus desplazamientos en segundo plano.

Hacer que la API aplique la confidencialidad

El inicio de sesión se basa en un número de teléfono y un código de verificación. El recorrido no exige foto, biografía ni identidad civil que presentar a los demás participantes. Eso no convierte el servicio en anónimo: ciertos datos de cuenta y de participación siguen siendo necesarios para su funcionamiento.

En el lugar, cada uno puede indicar una seña del momento, por ejemplo «mochila amarilla». Las dos señas se revelan después de las dos declaraciones de llegada. Esta regla se aplica en las respuestas del servidor: ocultar un campo en pantalla no bastaría. La lista de actividades no contiene esta información.

Las sesiones son revocables y sus tokens se conservan en forma de huellas en la base. En el lado móvil, las respuestas asíncronas se vinculan a la sesión que las solicitó. Una petición antigua no debe volver a mostrar datos después de un cambio de cuenta.

Prever la explotación desde la construcción

El soporte dispone de una interfaz interna distinta de la aplicación móvil, con su propio servidor, su autenticación y un rol SQL dedicado. Las solicitudes pueden seguirse, asignarse, resolverse y reabrirse cuando un usuario aporta información adicional.

Las acciones sensibles quedan registradas. Las versiones de los expedientes permiten detectar una modificación que ha quedado obsoleta, por ejemplo cuando dos personas trabajan sobre el mismo asunto. Los nuevos intentos tras un corte de red también se tienen en cuenta.

El desarrollo avanza por funcionalidades completas: reglas de negocio, API, persistencia, interfaz y, por último, verificación del recorrido. Las pruebas unitarias cubren las decisiones; las pruebas de integración verifican las restricciones de la base de datos; las pruebas de interfaz ponen a prueba los errores, las reanudaciones y las desconexiones. Los escenarios que usan proveedores simulados se mantienen diferenciados de las pruebas con servicios y dispositivos reales.

Lo que queda

El proyecto dispone de un recorrido de creación y participación implementado, de una búsqueda geográfica, de reglas de confidencialidad verificables y de una herramienta de soporte. El desarrollo continúa, en particular, con las notificaciones, la cualificación de las integraciones externas y de los recorridos en dispositivos físicos, así como el refinado de la interfaz antes de la distribución móvil.

El sitio de presentación del producto ya es público. Se genera en HTML estático en las 24 lenguas oficiales de la Unión Europea. Su animación sincroniza dos teléfonos para explicar el recorrido; es una representación del producto, no una captura de la aplicación nativa. El sitio funciona sin rastreadores publicitarios ni herramientas de analítica en el lado del visitante.

La aplicación móvil sigue en desarrollo en el momento de escribir esta nota. Por tanto, todavía no presentamos resultados de uso ni de despliegue a gran escala. El trabajo documenta una exigencia más inmediata: hacer que un gesto sea simple para el usuario sin dejar sus reglas al azar de la red, del reloj o de la interfaz.

Ficha técnica

Tecnologías empleadas: TypeScript, React Native, Expo, Fastify, PostgreSQL, PostGIS, React y Vite para la administración, Vitest y Docker. Sitio estático HTML, CSS y JavaScript, generación con Node.js y alojamiento en Railway.

Alcance: diseño de producto, arquitectura, desarrollo móvil y de servidor, administración, pruebas y sitio multilingüe.

Estado: producto de Scopes, aplicación móvil en desarrollo en 2026. El nombre del producto se omite en esta nota; se comparte a petición.

¿Prepara una aplicación móvil con reglas de negocio que no deben depender de la red? Scopes diseña y desarrolla aplicaciones iOS y Android desde Montpellier: consulte nuestra página de desarrollo móvil en Montpellier o descríbanos su contexto.