Evaluar proyecto

Evidencia · Codridge

Casos de éxito

Evidencia técnica de software a medida: problema, restricciones, arquitectura, decisión y resultado observable. Sin “transformamos digitalmente al cliente”.

Evaluar proyecto

Ver ejemplos

Método

Cómo leemos un caso

Cada caso prioriza restricción y decisión técnica. Cuando hay NDA, no nombramos al cliente: la industria y el aprendizaje siguen siendo útiles para evaluar si Codridge encaja con tu operación. Relacionado: desarrollo de software a medida.

Casos

4 proyectos tipificados

Logística Media

Integración entre tres sistemas en operación logística

Problema

El proceso dependía de validación manual entre tres sistemas. Pedidos, inventario y facturación se reconciliaban por planillas al cierre del día.

Restricciones

  • Sin downtime prolongado en horario operativo
  • ERP legado con API parcial y documentación incompleta
  • Equipo interno sin capacidad de mantener un middleware complejo

Arquitectura

Capa de integración con colas, transformaciones idempotentes y registro de auditoría. El ERP y el WMS quedaron como fuentes de verdad por dominio; la capa solo orquesta.

Decisión técnica

No reemplazar el ERP. Reducir fricción con una capa intermedia observable, en lugar de un “sistema total” que nadie podía migrar a tiempo.

Solución

Se diseñó una capa de integración que consolidó la información y eliminó la doble digitación en el flujo pedido → stock → factura.

Stack

  • TypeScript
  • Node.js
  • PostgreSQL
  • Colas/eventos
  • API REST

Resultado observable

Cierre diario sin planilla puente. Errores de conciliación detectados en minutos, no al día siguiente. Operación mantiene el ERP existente.

Aprendizajes

  • La integración bien acotada suele ganar a un rewrite completo.
  • La auditoría importa tanto como el “happy path”.

Relacionado: Integraciones API

Construcción Alta

Sistema interno de control de avance en obras

Problema

El seguimiento de avance vivía en planillas por obra. Gerencia no tenía una vista confiable; cada jefe de terreno usaba su propia estructura.

Restricciones

  • Usuarios en terreno con conectividad irregular
  • Roles distintos: terreno, oficina técnica, gerencia
  • Necesidad de evidencias fotográficas por hito

Arquitectura

Aplicación web + API con modo offline-friendly en captura, sincronización diferida, roles por obra y almacenamiento de archivos con control de acceso.

Decisión técnica

Priorizar captura en terreno y reporting gerencial antes que un módulo financiero completo. El primer entregable debía reducir incertidumbre semanal.

Solución

Portal interno con registro de hitos, evidencia, estados por obra y tablero gerencial alimentado por los mismos datos de terreno.

Stack

  • TypeScript
  • React
  • PostgreSQL
  • Object storage
  • Roles/ACL

Resultado observable

Una sola fuente de avance por obra. Reportes semanales generados desde el sistema, no desde correos con adjuntos.

Aprendizajes

  • En terreno, la UX simple supera al dashboard bonito.
  • Roles mal modelados generan más soporte que features nuevas.

Relacionado: Sistemas empresariales

Servicios Alta

Plataforma SaaS B2B para prestación de servicios

Problema

La empresa vendía un proceso propio empaquetado en planillas y WhatsApp. Querían producto: multi-cliente, permisos y API para partners.

Restricciones

  • Salida a producción con un vertical piloto, no con todos los clientes
  • Billing externo ya contratado
  • Requisito de API estable para un partner estratégico

Arquitectura

Multi-tenant lógico por cuenta, API versionada, panel admin, webhooks de billing y separación clara entre dominio de negocio y entregas de partner.

Decisión técnica

Empezar por un vertical con reglas cerradas. Evitar “configurable infinito” en el MVP: configurabilidad sin producto es deuda.

Solución

SaaS con onboarding por cuenta, roles, flujo operativo del servicio y API para el partner. Billing integrado por webhooks.

Stack

  • TypeScript
  • Node.js
  • PostgreSQL
  • API versionada
  • Webhooks

Resultado observable

Primeros clientes operando sin planillas. Partner consumiendo API sin accesos ad hoc. Backlog de verticales siguientes priorizado con datos reales.

Aprendizajes

  • Multi-tenant temprano obliga a disciplina de datos.
  • La API es producto: versionar desde el día uno.

Relacionado: Plataformas SaaS

Ecommerce Acotada

Automatización de conciliación de pedidos y pagos

Problema

Órdenes de la tienda, pasarela y ERP se conciliaban a mano. Picos de campaña saturaban a finanzas.

Restricciones

  • No tocar el checkout en campaña
  • Pasarela y ERP con límites de rate
  • Necesidad de excepciones humanas visibles

Arquitectura

Worker de conciliación programado, reglas de matching, cola de excepciones y panel mínimo para resolver casos no automáticos.

Decisión técnica

Automatizar el 80% matchable y diseñar bien el 20% excepcional. No prometer “100% automático” con datos sucios.

Solución

Job de conciliación con reporte diario, excepciones encoladas y escritura controlada al ERP solo cuando el match es inequívoco.

Stack

  • Python
  • PostgreSQL
  • Jobs programados
  • API pagos
  • API ERP

Resultado observable

Horas de conciliación manual reducidas en días de campaña. Excepciones quedan trazables en lugar de vivir en hilos de correo.

Aprendizajes

  • Las excepciones son parte del producto.
  • Rate limits ajenos definen la arquitectura tanto como el dominio.

Relacionado: Automatización de procesos

Siguiente

Sigue por aquí

Ejemplos casos de uso tipificados Software a medida servicio Calculadora estimar complejidad Evaluación técnica contacto

¿Tu problema se parece a alguno de estos?

Contanos industria, restricciones y sistemas actuales. Evaluamos si hay un primer entregable con resultado observable.

  • Arismendi Transportes
  • Falabella
  • Walmart
  • RTIAP
  • MB Services
  • WantedCars
  • Operaciones reales en Chile
  • Respuesta en días hábiles