Hace unas semanas conté acá cómo armé, con ayuda de una IA, un sistema para que mi minimarket dejara de recibir pedidos de productos agotados en la app de delivery. En ese momento sonaba "resuelto". La realidad es que fue el comienzo — desde entonces pasaron bastantes cosas que vale la pena compartir, sobre todo porque casi todo lo que aprendí vino de fallas reales en producción, no de la planificación inicial. El primer susto: el sistema empezó a apagar productos que sí tenían stock Con el sistema funcionando, un día empezó a desactivar productos que sí tenían stock disponible. La causa: mi script mandaba una actualización por producto, una por una, y en cada corrida completa eran más de mil llamadas seguidas. La plataforma de delivery las aceptaba, pero las dejaba encoladas sin llegar a aplicarlas realmente — mis actualizaciones "se perdían" en el camino sin ningún error visible en el momento. @Cristian Tala me hizo notar, antes incluso de que soporte técnico me lo confirmara, que agrupar todo en una sola llamada por corrida (en vez de mil llamadas sueltas) reduciría el cuello de botella. Aprendizaje: si algo "se pierde" sin dar ningún error, sospecha de volumen antes que de lógica. Rediseño: avisar solo de lo que cambió, y en un solo envío La solución de fondo fue doble: 1. Guardar el último estado conocido de cada producto, y avisar a la plataforma solo cuando algo realmente cambia (no reenviar los ~1000 productos en cada corrida). 2. Agrupar todos los cambios detectados en un único envío por corrida, en vez de uno por producto. Con eso, una corrida típica pasó de tardar 12-20 minutos a menos de un minuto, y el problema de actualizaciones perdidas desapareció. Un costo que no había considerado: los minutos de cómputo Corriendo cada 5-10 minutos las 24 horas, calculé que podía agotar la cuota gratuita de mi proveedor de automatización (GitHub Actions) en cuestión de días, no de meses. La solución fue simple una vez identificado el problema: hacer que el sistema solo corra durante el horario real de atención del negocio, y con más frecuencia en las horas de mayor demanda (18 a 22 hs) que en el resto del día. Fuera de ese horario, no corre nada. Con esto, y con la optimización de velocidad del punto anterior, el consumo real terminó siendo menos del 10% de la cuota gratuita mensual.

Llevo un buen tiempo construyendo LYNX, un motor que encuentra decisores B2B y les hace el primer contacto hasta dejar reuniones agendadas. Esta semana firmé y cobré mi primer contrato con una empresa de ciberseguridad. Lo cuento acá porque entré a la comunidad hace un par de semanas convencido de que mi próximo paso era levantar capital ángel, tenía un par de reuniones agendada y todo, pero en una conversación que tuve por acá me bajaron a tierra, diciendome que el mejor financiamiento es el cliente, y me faltaba tracción, no plata. Piqué el anzuelo, me puse a cerrar en vez de a pitchear inversionistas, y acá está el resultado. Sigue siendo uno solo, y sé que un cliente no es una empresa todavía, pero pasé de "tengo una idea que creo que sirve" a "alguien puso plata", y ese salto se sintió distinto a todos los anteriores. Gracias @Cristian Tala por el sacudón. Ahora a buscar el siguiente cliente.

Hoy recibí un regalo de $7.500 USD en infraestructura con GPUs NVIDIA. Al revisar las opciones disponibles, me encontré con dos alternativas principales: 1. A100 SXM (40GB VRAM) a $1,99/hr: Queda muy al límite para un modelo como Qwen 2.5 72B-AWQ (que pide ~36GB solo en pesos). Nos forzaría a bajar a un modelo de 32B o sacrificar la concurrencia y el KV cache. 2. H100 PCIe (80GB VRAM) a $3,29/hr: Es la mejor opción. Nos da espacio suficiente para el modelo 72B-AWQ, el draft model y soporte para cientos de peticiones concurrentes sin saturar la GPU. El desafío principal es que este servicio cobra por hora, no por token. Puedo procesar todo el volumen que la velocidad del sistema me permita, pero si no mantengo un tráfico mínimo, desperdicio cómputo y dinero. Mi objetivo principal es construir un chatbot de ventas automatizado. Sin embargo, viendo la visión de Jensen Huang sobre el ecosistema de startups, el síndrome del impostor atacó fuerte: tener semejante potencia de cálculo te hace dudar de si la estás usando en algo lo suficientemente grande. Si tuvieran esta infraestructura a disposición, ¿cómo la aprovecharían al máximo? Los leo 👇 https://youtu.be/RlXZlh90zIs?si=qdql9QxVer9SGmGJ

Quiero compartir esto porque creo que es un buen ejemplo de un problema súper común para pequeños negocios, y de cómo una IA puede ayudarte a resolverlo de punta a punta aunque no tengas background técnico. El problema Tengo una botillería. Para el negocio del día a día (ventas, inventario, control de stock) uso una plataforma tipo ERP/POS. Para vender a través de delivery, uso el portal de administración de PedidosYa, donde manejo el catálogo de productos que ven los clientes. El problema: estas dos plataformas no se hablan entre sí. Cuando un producto se agotaba en el negocio (stock 0), seguía apareciendo disponible en la app. Resultado: clientes pedían productos que no tenía, teníamos que llamarlos para ofrecer un cambio, muchas veces no contestaban, se cancelaba el pedido, nos llegaban malas calificaciones, y hasta descuentos por parte de la plataforma de delivery por estas cancelaciones. Un dolor de cabeza recurrente que nos costaba plata y tiempo. Cotizar una integración a medida con una agencia no tenía sentido para el tamaño de mi negocio. Así que decidí intentarlo con Claude. Lo que hicimos (resumen del proceso) 1. Investigamos si existía una integración nativa entre ambas plataformas. No la había (solo existía integración para logística de despacho, no para el catálogo). 2. Confirmamos que ambas plataformas tenían API pública. Ese fue el punto de partida: si ambas tienen API, se puede construir un puente entre ellas. 3. Armamos un script en Python que: - Cada cierto tiempo, consulta el stock real de cada producto en el sistema de inventario - Si un producto llega a 0, llama a la API de la tienda de delivery y lo desactiva automáticamente - Si vuelve a tener stock, lo reactiva solo - Lo alojamos gratis en GitHub Actions, corriendo en un horario automático (cron), sin necesidad de un servidor propio ni pagar hosting. - Fuimos resolviendo obstáculos reales sobre la marcha, que es donde realmente se aprende: - Conseguir credenciales de ambas plataformas (algunas requirieron contactar soporte técnico) - Un dolor de cabeza inesperado: el mismo producto tenía el código con un "0" adelante en un sistema y sin el 0 en el otro (por un tema de lector de código de barras) — el script terminó adaptado para probar automáticamente ambas variantes - Descubrir que algunos productos eran "combos" armados especialmente para la app de delivery, que no existen como tal en el inventario — hubo que excluirlos del sistema automático para no desactivarlos por error - Optimizar el tiempo de ejecución: la primera versión tardaba ~23 minutos en recorrer todo el catálogo (~1000 productos); con un ajuste técnico (eliminar una llamada innecesaria a la API) bajó a 12-14 minutos - Rotar las credenciales una vez confirmado que todo funcionaba, por buena práctica de seguridad

Anoche (o mejor dicho, en la madrugada) logré conectar una impresora de etiquetas e imprimir desde un microservicio en Deno. Puede parecer un avance pequeño, pero para mí fue un hito importante. Nunca había trabajado con este tipo de dispositivos y verlo funcionando fue una de esas pequeñas victorias que te recuerdan que el proyecto ya está tomando forma. El proyecto busca optimizar el ingreso de productos para una tienda tipo outlet hogar, donde cada artículo puede tener distintas condiciones y el flujo tiene muchos casos borde. El objetivo es que un producto pueda ingresar en el menor tiempo posible y quedar listo para el POS, e-commerce y los sistemas internos con la menor intervención manual posible. Para eso estoy construyendo una arquitectura basada en microservicios con Deno, React (app web) y React Native (app movill) para las interfaces, Supabase como base de datos y algunas APIs de IA para automatizar tareas como generar descripciones, mejorar fotografías y obtener precios referenciales a partir de imágenes. Me tomó bastante tiempo definir el flujo y la arquitectura porque intenté contemplar todos los casos posibles. Al final decidí priorizar una base sólida e ir ajustando los casos borde con el uso real. Me encantaría conocer opiniones sobre el enfoque o sugerencias de quienes hayan construido sistemas similares.