El equipo trabaja alrededor del sistema
Exporta, corrige y vuelve a cargar porque la secuencia real no entra en las pantallas disponibles.
Construimos paneles internos, portales y plataformas cuando una herramienta de mercado obliga a tu operación a trabajar alrededor del software.
Los permisos y la vista cambian según el rol: producción, compras y dirección nunca ven la misma pantalla.
Trabajamos sobre lo que tu equipo ya sabe usar. Si la plataforma tiene API o webhooks, se integra; si no, buscamos el camino más estable antes de proponer un cambio de herramienta.
Y cualquier otra plataforma con API pública.
Reparten para varios clientes con camionetas propias y con fleteros contratados por zona. Todos los sistemas que habían probado dan una entrega por cerrada o por fallida, y en esta operación un pedido puede volver con la mitad de las cajas adentro. Construimos el software alrededor de ese caso y lo pusimos a andar en una zona antes de sumar el resto.
Logística de última milla · Argentina
Los sistemas de reparto tratan una parada como sí o no: firmó o no firmó. Acá el que recibe puede rechazar parte del pedido en la puerta —cajas dañadas, cantidad que no coincide con la orden— y lo que vuelve define tres cosas distintas: qué se redespacha, qué se le factura al cliente y cuánto se le liquida al fletero. Con una herramienta comprada hecha eso terminaba escrito en el campo de observaciones, y alguien lo volvía a tipear en una planilla el lunes.
En vez de reemplazar toda la operación, acotamos la primera versión a lo que dependía de la devolución parcial: cargar desde el celular qué volvió y con qué motivo, y que de ahí salgan la liquidación y el resumen para facturar. El armado de rutas quedó afuera a propósito y se siguió haciendo con lo que ya usaban. Salió a producción en un depósito, con los choferes de esa zona, y recién después se sumaron los demás.
El chofer ve el viaje del día y cierra cada parada marcando línea por línea qué entregó y qué vuelve, con el motivo elegido de una lista cerrada. La mesa de operaciones ve las paradas que cerraron con diferencia y decide si se redespacha. Administración ve la liquidación por fletero del período y el resumen por cliente. Cada rol entra a su pantalla y no a las otras, en lugar del Excel compartido que veían todos. Los pedidos se siguen tomando del sistema del cliente por archivo o por API, y el resumen se manda al sistema contable que ya tenían: no reemplazamos nada que funcionara.
Las tarifas por zona, los motivos de devolución y las reglas de cada cliente se cargan desde una pantalla de administración: sumar un cliente nuevo es cargar sus reglas, no pedir un desarrollo. Quedó un documento corto que explica cada pantalla, cada estado y qué pasa cuando una parada cierra con diferencia. Las mejoras se anotan en una lista y se ordenan una vez por mes: entra lo que traba la operación de hoy, el resto espera.
La misma mecánica sirve para cualquier operación donde el trabajo no termina en sí o no: un laboratorio donde una muestra se rehace, una constructora que certifica avance parcial de obra, un service que deja un equipo funcionando a medias. Cambian el vocabulario y los estados, no la forma de construirlo.
No todo proceso merece código propio. Pero si adaptar la operación a una herramienta elimina una ventaja, multiplica planillas o exige demasiados parches, construir puede ser la opción más simple.
Exporta, corrige y vuelve a cargar porque la secuencia real no entra en las pantallas disponibles.
Pedidos, documentos y estados se resuelven por correo porque no existe un portal que reúna el circuito.
Los reportes requieren consolidar fuentes manualmente y muestran lo que pasó cuando ya no se puede intervenir.
No reemplazamos cada herramienta. Diseñamos la pieza que falta y la integramos para que el usuario vea un flujo, aunque por detrás participen varios sistemas.
Colas de trabajo, prioridades, estados, alertas y responsables en una vista construida para decidir.
Carga de pedidos, documentos, seguimiento y comunicación sin depender de cadenas de correo.
Reglas, aprobaciones y excepciones específicas que un producto genérico no representa bien.
APIs, sincronización, identidad y reportes para que la nueva plataforma no se convierta en otro silo.
La arquitectura se diseña para crecer, pero el proyecto se valida con una parte operativa real. Cada entrega tiene usuarios, datos y un resultado observable.
Quién usa el sistema, qué necesita resolver y qué dato permite avanzar.
Pantallas y reglas navegables antes de invertir en la implementación completa.
Entregas pequeñas, integradas y probadas con usuarios del proceso.
Monitoreo, soporte, documentación y evolución sobre evidencia de uso.
El proyecto cubre producto, interfaz, ingeniería y salida. No entregamos código sin el contexto necesario para operarlo y hacerlo evolucionar.
Cuando el proceso es una ventaja, ninguna herramienta encaja sin cambios costosos o la fragmentación actual ya cuesta más que sostener una solución propia.
Elegimos el stack según el problema, el equipo que lo va a mantener, integraciones, seguridad y escala. La tecnología se documenta y no se decide por moda.
El alcance contractual define propiedad y accesos desde el comienzo. La empresa recibe repositorio, documentación y control del despliegue acordado.
Depende del alcance. Trabajamos con una primera entrega utilizable y fases posteriores, para validar antes de comprometer meses a una solución completa.
Sí. Podemos acompañar operación, incidentes y evolución, con responsabilidades y niveles de servicio definidos según la criticidad del sistema.
Evaluamos si realmente necesita software propio o si alcanza con configurar e integrar lo que ya existe.
Kai Agente de Kommit · En línea
¡Hola! Soy Kai, el agente de Kommit. Contame qué proceso te está costando horas y te digo por dónde conviene empezar.
Agente de IA: puede equivocarse. Lo que acordemos lo confirma el equipo. Preferís el formulario →