Saltar al contenido
04 / 07Sistemas a medida

Desarrollo de sistemas a medida para operaciones únicas

Construimos paneles internos, portales y plataformas cuando una herramienta de mercado obliga a tu operación a trabajar alrededor del software.

Panel de operaciones · Producción A medida
Órdenes abiertas 37 Turno mañana · Planta 2
Entregas por semana Últimas 8 semanas
Piso de planta
  • OT-2481 · Corte y plegado En curso
  • OT-2479 · Pintura Listo
  • OT-2486 · Armado final En cola
Pedido #2481 · Distribuidora Sur Supera el límite de crédito. Necesita tu aprobación. Aprobar pedido

Los permisos y la vista cambian según el rol: producción, compras y dirección nunca ven la misma pantalla.

Construido sobre
  • PostgreSQL
  • Supabase
  • Stripe
  • Mercado Pago
Ver cómo lo armamos
Con las herramientas que ya usás

Se conecta con tu stack, no lo reemplaza

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.

  • PostgreSQL
  • Supabase
  • Stripe
  • Mercado Pago
  • Google Sheets
  • Notion

Y cualquier otra plataforma con API pública.

Caso de implementación

Un sistema construido alrededor de la entrega que vuelve a medias

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

  1. Ningún producto enlatado contemplaba la devolución parcial

    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.

  2. La primera entrega cubrió solo ese circuito

    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.

  3. Tres pantallas, una por rol, y lo demás quedó donde estaba

    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.

  4. Lo que cambia seguido se cambia sin programar

    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.

Cuándo hace falta

El software estándar deja de servir cuando borra tu diferencia

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.

El equipo trabaja alrededor del sistema

Exporta, corrige y vuelve a cargar porque la secuencia real no entra en las pantallas disponibles.

El cliente no tiene una experiencia propia

Pedidos, documentos y estados se resuelven por correo porque no existe un portal que reúna el circuito.

La información llega tarde

Los reportes requieren consolidar fuentes manualmente y muestran lo que pasó cuando ya no se puede intervenir.

Qué construimos

Software propio conectado con lo que ya funciona

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.

Capacidad 01

Paneles operativos

Colas de trabajo, prioridades, estados, alertas y responsables en una vista construida para decidir.

Capacidad 02

Portales de clientes y proveedores

Carga de pedidos, documentos, seguimiento y comunicación sin depender de cadenas de correo.

Capacidad 03

Aplicaciones de proceso

Reglas, aprobaciones y excepciones específicas que un producto genérico no representa bien.

Capacidad 04

Datos e integraciones

APIs, sincronización, identidad y reportes para que la nueva plataforma no se convierta en otro silo.

Cómo lo desarrollamos

Una primera versión que resuelve, no una maqueta eterna

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.

  1. Etapa 01

    Definimos la decisión central

    Quién usa el sistema, qué necesita resolver y qué dato permite avanzar.

  2. Etapa 02

    Prototipamos el flujo

    Pantallas y reglas navegables antes de invertir en la implementación completa.

  3. Etapa 03

    Construimos por módulos

    Entregas pequeñas, integradas y probadas con usuarios del proceso.

  4. Etapa 04

    Operamos y mejoramos

    Monitoreo, soporte, documentación y evolución sobre evidencia de uso.

Alcance

Qué incluye el desarrollo de software a medida

El proyecto cubre producto, interfaz, ingeniería y salida. No entregamos código sin el contexto necesario para operarlo y hacerlo evolucionar.

Incluido en el proyecto

  • Descubrimiento y definición de alcance
  • Arquitectura de información y prototipo UX
  • Diseño visual responsive y accesible
  • Desarrollo frontend, backend e integraciones
  • Pruebas, seguridad, logs y despliegue
  • Documentación, capacitación y soporte
Preguntas frecuentes

Lo que conviene saber antes de empezar

¿Cuándo conviene desarrollar un sistema a medida?

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.

¿Qué tecnologías usan?

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 código queda para la empresa?

El alcance contractual define propiedad y accesos desde el comienzo. La empresa recibe repositorio, documentación y control del despliegue acordado.

¿Cuánto tarda un desarrollo a medida?

Depende del alcance. Trabajamos con una primera entrega utilizable y fases posteriores, para validar antes de comprometer meses a una solución completa.

¿Incluyen mantenimiento?

Sí. Podemos acompañar operación, incidentes y evolución, con responsabilidades y niveles de servicio definidos según la criticidad del sistema.

El siguiente paso

Mostranos el proceso que ninguna herramienta pudo resolver bien

Evaluamos si realmente necesita software propio o si alcanza con configurar e integrar lo que ya existe.