Santino Spingola

El problema

Un equipo comercial vendía sobre planillas compartidas y mensajes directos. Nadie sabía cuánto tardaba el equipo en responder un lead, las oportunidades se enfriaban sin que nadie lo notara, y el dueño no podía ver el rendimiento del equipo sin preguntar uno por uno.

La solución

Una plataforma multi-empresa que unifica contactos, catálogo con precios y promociones vigentes, pipeline con cronómetro de primera respuesta, y las conversaciones de WhatsApp dentro del mismo sistema.

Mi participación

• Arquitectura, base de datos, backend, interfaz, pruebas y despliegue: todo.
• 5 módulos, 35 tablas, ~27.700 líneas de TypeScript.
• 169 pruebas automatizadas y 6 compuertas de calidad en verde.

Decisiones de ingeniería

• Aislamiento por RLS en la base, no en el código, con una prueba que intenta la fuga entre empresas.
• Bus de eventos persistido con outbox transaccional, manejadores idempotentes y cola de fallidos operable.
• Puertos y adaptadores: 8 integraciones con dobles funcionales —incluido un puerto de IA para clasificación y resúmenes.
• Capa anticorrupción sobre la API de WhatsApp: tolera payloads desconocidos sin cortar el servicio.

Producción

• Supabase y Vercel en São Paulo, con driver dual: Postgres embebido en desarrollo y pruebas.
• Capacitación y soporte continuo al equipo comercial que lo opera a diario.

El problema

Una inmobiliaria recibe todos los días las mismas consultas: si la propiedad sigue disponible, qué requisitos piden, cuánto es el depósito, si se puede visitar el sábado. Llegan fuera de horario, se acumulan, y cada respuesta tardía es una visita que no se agenda.

La solución

Un agente conversacional que responde disponibilidad, condiciones y requisitos, agenda visitas dentro de la misma conversación, analiza imágenes de propiedades y mantiene el contexto entre mensajes.

Arquitectura

• Interfaz en Next.js sobre Vercel; la lógica del agente vive en un flujo de n8n.
• El webhook nunca llega al navegador: el cliente llama a /api/chat y el servidor reenvía a n8n.
• El contexto se sostiene con un sessionId; la memoria vive en el flujo, no en la interfaz.
• La respuesta de n8n se lee de forma defensiva, para que ajustar el flujo no rompa la interfaz.

El problema

Producir contenido de marketing consumía horas del equipo cada semana, y el resultado no mantenía una voz de marca consistente entre quien lo escribía y quien lo diseñaba.

La solución

Un panel con cuatro módulos: biblioteca de marca que analiza material previo para construir el perfil de la empresa, creador de posteos con slides ya renderizados como imagen, generador de guiones de video, y editor que corta silencios y arma el video vertical con subtítulos.

Decisiones sobre el uso de IA

• El motor LLM es Claude Code en modo headless, no la API: usa la sesión del plan del servidor en lugar de facturar por token.
• Cada llamada se registra con módulo, duración, resultado y consumo.
• Al alcanzar el límite del plan, la interfaz lo informa en vez de fallar en silencio.
• La aplicación levanta completa aunque el motor de IA no esté configurado.

El problema

Cuando un negocio se cerraba en el CRM, alguien del equipo administrativo tenía que volver a cargar el cliente y el comprobante de venta a mano en el ERP. Doble carga, demoras y errores de tipeo entre dos sistemas que no estaban pensados para comunicarse.

La solución

Dos microservicios que cierran el circuito: uno crea las notas de pedido en Bejerman sobre su SDK SOAP, y otro da de alta al cliente en BAS cuando el negocio avanza de etapa en Bitrix24.

Mi participación

• Relevamiento del contrato SOAP con SoapUI: el ERP no tenía documentación pública de API.
• Servicio Node.js/Express que arma el comprobante completo —ítems, IVA, punto de venta, condición de venta— y devuelve la respuesta parseada al CRM.
• Autenticación OAuth2 contra BAS con caché y renovación anticipada del token.
• Despliegue con infraestructura declarada en código.

El problema

Cada sistema de gestión para una PyME arrancaba de cero repitiendo lo mismo: usuarios, permisos, aislamiento por cliente, eventos, manejo de dinero y fechas. Semanas de trabajo antes de escribir una línea del negocio real.

La solución

Extraje el núcleo de Órbita a una base reutilizable sin dominio de negocio: identidad, sesiones, permisos, multi-tenancy con RLS, bus de eventos, cifrado de secretos y puertos de integración con mocks. Sumar un módulo son tres declaraciones.

Construido encima

• Servicios de electricidad: clientes, presupuestos, materiales y agenda.
• Distribución mayorista: motor de precios con listas, escalas y bonificaciones, más facturación electrónica.
• Análisis funcional de cinco rubros —consultorio, taller, inmobiliaria, servicio técnico en campo y distribución—, definiendo entidades y reglas de negocio antes de escribir código.