Programación de shuttles y cuadrillas

El reto

Los pequeños operadores de servicios —cuadrillas de limpieza, vans de shuttle, rutas de mensajería— organizan el horario de mañana en un grupo de WeChat y una hoja impresa. Cambia un turno, el despachador publica un mensaje y se entera quien alcance a leer hasta ahí. Nadie tiene registro de quién aceptó qué, y al final de la semana las horas se reconstruyen de memoria.

Estas cuadrillas son bilingües y muchas veces predominantemente chinohablantes. Las herramientas de programación que se venden en este mercado están pensadas primero en inglés y dan por hecho un escritorio con wifi estable. Un conductor en un estacionamiento subterráneo o una persona de limpieza en un pasillo de servicio del sótano no tiene señal justo en el momento en que el horario más importa. La brecha no está en las funciones. Está en el idioma y en la conectividad.

Lo que construimos

Este es un producto propio de Porcelain Tech Studio, en desarrollo activo. Ningún cliente lo encargó y nada se ha lanzado. Lo estamos construyendo porque la arquitectura de backend compartido que está detrás de nuestro sitio web necesitaba un segundo cliente genuinamente distinto para ponerla a prueba: uno móvil, tolerante a la falta de conexión y nada parecido a un navegador.

React Native sobre Expo, una sola base de código para iOS y Android. Se comunica con el mismo servicio FastAPI y la misma base de datos PostgreSQL que sirven al sitio web: la misma autenticación de sesión, el mismo health check, la misma ruta de despliegue. Sin un segundo backend y sin duplicar el modelo de usuario.

• Las listas de trabajo se muestran primero desde el almacenamiento local y se reconcilian con el servidor cuando vuelve la señal. Abrir el trabajo del día nunca espera a la red.
• Un cambio de turno se ofrece con un toque y se acepta con otro, y la aceptación escribe un registro. Un relevo deja de ser un mensaje de chat que alguien pudo no haber visto.
• Una vista de supervisor muestra hoy, mañana y cada espacio sin cubrir.
• Inglés y chino se publican en el mismo build, desde la primera pantalla. El idioma es un campo del registro, no una capa de traducción agregada al final.

Resultado

El desarrollo sigue en curso, así que las cifras de aquí son las metas que rigen la construcción, no resultados que estemos afirmando.

Cuatro endpoints se reutilizan sin cambios desde la API del sitio web. Dos plataformas salen de una sola base de código. La lista de trabajos abre con cero peticiones de red, y eso es una restricción que da forma a la capa de datos local, no una función agregada después.

El resultado útil es arquitectónico. Construir un cliente móvil contra el mismo contrato obligó a que ese contrato dejara de asumir un navegador. Cualquier trabajo de app que tomemos de aquí en adelante parte de una API que ya sirvió a dos consumidores muy distintos.