Devlog: ya se puede crear y gestionar un envío en Movo (transportarlo es otra historia)

Segunda entrega de la serie. En la anterior contamos cómo construimos la identidad y la confianza entre usuarios. Esta vez tocaba la parte que le da sentido a todo lo demás: que un envío se pueda crear, publicar y gestionar.

Aclaración antes de arrancar, porque el título de esta serie se presta a confusión: lo que cerramos es la publicación y gestión del envío, no el transporte en sí. Todavía no hay forma de que un transportista se postule a llevar un paquete, ni de coordinar el retiro, el viaje o la entrega. Eso viene después, y depende en parte de lo que contamos más abajo sobre pagos.

Un emisor puede crear un envío desde un wizard en el celular, con fotos del paquete y un precio sugerido automáticamente. Elige a quién se lo envía y la ruta, con autocompletado de direcciones. Esa persona —el receptor, quien va a recibir el paquete en destino— ve el envío, ve la reputación de quien se lo manda, y decide si lo acepta o lo rechaza. Ambas partes reciben notificaciones push en los pasos importantes. Si nadie confirma a tiempo, el envío vence solo. Se puede cancelar mientras todavía no tiene transportista asignado. Y el emisor puede repasar el historial completo con una línea de tiempo de estados.

Ninguna de esas piezas asigna todavía un transportista real al envío ni mueve el paquete. Lo que queda armado es la parte de "publicar y coordinar", que es el prerrequisito para que ese matching tenga sentido.

En paralelo resolvimos dos investigaciones técnicas de riesgo alto que veníamos posponiendo: el algoritmo que va a calcular rutas óptimas para los transportistas (con OR-Tools, la librería de optimización de Google), y la integración de pagos con MercadoPago.

El precio sugerido que ve el emisor hoy es una implementación lineal provisoria, con un fallback si algo falla —no calcula todavía rutas óptimas de verdad. Pero antes de construir eso en serio necesitábamos saber si el problema real (calcular la mejor combinación de rutas para varios transportistas y envíos a la vez, lo que se conoce como VRPTW) se podía resolver en tiempos razonables. Es uno de los riesgos técnicos más altos del proyecto: si la librería no daba abasto, iba a haber que rediseñar buena parte del sistema de precios y matching.

Le dedicamos dos días a probar OR-Tools, la librería de optimización de Google, contra volúmenes de datos representativos. Convergió en tiempos razonables. Es una buena noticia, aunque con una salvedad: falta validarlo con volumen real de producción, que es distinto a los datos de prueba que usamos.

Parte del modelo de negocio de Movo depende de un mecanismo específico de MercadoPago: retener el dinero del emisor sin cobrarlo (un hold), y cuando se confirma la entrega, repartir automáticamente ese pago entre el transportista y la comisión de Movo en la misma operación (lo que MercadoPago llama split payment, vía application_fee).

Probamos las dos piezas por separado en su entorno de pruebas y funcionan: el hold se puede crear sin cobrar (con capture:false) y se puede cancelar sin problema, y la cuenta del transportista se puede conectar a Movo por OAuth para operar pagos en su nombre. Lo que no funciona es combinarlas: pedir el hold con el reparto de comisión incluido devuelve un error genérico ("usuarios inválidos"), sin más detalle. Probamos nueve configuraciones distintas —otra cuenta de prueba, otra aplicación, otro desarrollador del equipo, el SDK oficial en vez de armar la request a mano— para descartar que fuera un problema nuestro. En todos los casos, mismo error.

Abrimos un caso de soporte técnico con MercadoPago a mediados de agosto. Once días después, al cierre de este sprint, seguimos sin respuesta. No es un detalle menor: sin esto resuelto, Movo no tiene forma automática de cobrar su comisión, así que es el bloqueante más importante del proyecto en este momento, no un ítem más de la lista de pendientes.

Este bloqueo de pagos ya tiene un impacto concreto en lo que construimos este sprint: cancelar un envío que ya tiene transportista asignado debería, en algunos casos, aplicar una penalización monetaria. Como todavía no hay un mecanismo de pagos real para cobrarla, no lo simulamos a medias. El sistema devuelve directamente un error explícito diciendo que esa combinación puntual no está soportada por ahora.

Es la misma decisión que tomamos con el matching de transportistas: mejor una funcionalidad ausente y declarada así, que una a medio hacer que después genera comportamientos raros o deuda técnica escondida.

Además del tema de pagos, aparecieron dos bugs durante el desarrollo del wizard de envío. Los dos quedaron cargados como bugs en nuestro tracker por primera vez de forma sistemática —hasta el sprint anterior los corregíamos sin dejar ese registro, así que la métrica de defectos que llevamos internamente no reflejaba la realidad. Ahora sí.

Una investigación técnica puede validar la mayoría de lo que hacía falta y aun así dejar el punto más riesgoso sin resolver. Cuando pasa eso, conviene decirlo con esas palabras en vez de dar el tema por cerrado. Es la única forma de que el resto del equipo, y quien nos sigue desde afuera, tenga una foto real del estado del producto en vez de una versión optimista.

Bloquear explícitamente, con un mensaje de error claro, una funcionalidad que depende de una pieza que no está lista es mejor que dejarla funcionando a medias. Se nota menos en lo inmediato —hay menos para mostrar en la demo— pero evita sorpresas después.

Lo primero es destrabar el problema de pagos con MercadoPago, o encontrar un plan B si no hay forma de resolverlo del lado de ellos: es el bloqueante para que la comisión de Movo se cobre de forma automática, y sin eso no tiene mucho sentido avanzar en la persistencia y vinculación de métodos de pago del emisor y del transportista.

Recién con eso resuelto vamos a poder construir la parte que realmente le falta al producto: que un transportista pueda ofertar para llevar un envío, y que ese envío se retire, viaje y se entregue de verdad. Todavía no hay fecha para eso.

Gracias por seguir el progreso. Si querés enterarte apenas se resuelva el tema de pagos y de cuándo Movo esté disponible, seguinos en Instagram.