Portfolio

Cuatro trabajos reales. Cada uno arranca por el problema, porque es la parte en la que un lector se reconoce.

Comercio de consumo con reparto propio
Destacado
Suite PYMES — la gestión adentro de la tienda
Producto propio2026Comercio de consumo con reparto propio
Cliente
Producto propio
Rubro
Comercio de consumo con reparto propio
Año
2026
El problema
Un comercio de consumo con reparto propio decide todos los días qué reponer, a quién comprarle y cuánto cobrar el envío. Las plataformas de comercio electrónico resuelven la vidriera; el resto queda afuera.
Stock, costos de proveedor, liquidación de repartidores y rentabilidad real terminan en una planilla que alguien actualiza cuando puede, y en cuentas mentales que casi siempre están infladas.
Qué se construyó
Un sistema donde la venta y la gestión son la misma cosa. El pedido entra por la tienda, descuenta stock de forma atómica, se cobra con MercadoPago, emite factura electrónica automáticamente al marcarse pagado, se asigna a un repartidor y termina en un tablero contable.
Alrededor, el stack de atención: WhatsApp integrado a una bandeja unificada y un agente de IA que responde consultas con el catálogo y los precios vigentes.
Los detalles que hacen la diferencia
El margen que mentía a medias
Cuando el cliente pagaba el envío, ese importe sumaba como ingreso pero el pago al repartidor no se descontaba como costo. El problema quedó documentado con números, se plantearon las dos alternativas contables posibles con su efecto sobre el porcentaje, se consultó con un contador y solo entonces cambió la fórmula. El margen informado bajó, y pasó a ser el real.
El envío bonificado que no borra el costo
Cuando el carrito supera el mínimo, el cliente ve «envío gratis», pero el sistema guarda igual lo que ese reparto cuesta: para pagarle al repartidor, y para que el tablero muestre cuánto salió bonificarlo.
El día del negocio, no el del servidor
Los reportes agrupan las ventas por la zona horaria del comercio, que se deduce automáticamente del pin que el dueño marca en el mapa. Un pedido de las 22:00 se cuenta en su día, no en el día siguiente del reloj del servidor.
Ayuda que no envejece
En vez de un manual con capturas que quedan viejas al primer cambio, tours interactivos que señalan la pantalla real y recuerdan dónde quedó cada usuario.
Un presupuesto de IA que no se pasa
El sistema reserva el gasto antes de llamar al modelo, nunca después. Si no alcanza, no gasta un solo token y deriva la conversación a una persona.
Cómo se verificó
La verificación fue una auditoría propia en siete fases sobre 92 criterios de aceptación: inventario documental, contraste entre lo documentado y lo que hace el código, vigencia de cada dependencia, plan de pruebas, ejecución automatizada punta a punta con Playwright, revisión de seguridad y corrección verificada.
Aparecieron fallas que no se ven en una demostración: un colaborador podía fabricarse una cuenta de administrador; el campo del color de marca permitía inyectar código en todas las páginas públicas; era posible manipular el catálogo para que el agente de IA cotizara precios falsos; y bajo pedidos simultáneos el tope de gasto de IA se superaba en un 150%. Cada corrección quedó con su prueba de regresión.
Nada se marca «funciona» sin evidencia ejecutada. Lo que no se probó se entrega como no verificado, nunca como aprobado.
Stack
Next.js 16
TypeScript
PostgreSQL
Prisma
Tailwind CSS
Docker
MercadoPago
ARCA/AFIP
Google Maps
n8n
Chatwoot
Playwright
Producto relacionado: Suite PYMES
Un comercio de consumo con reparto propio decide todos los días qué reponer, a quién comprarle y cuánto cobrar el envío. Las plataformas de comercio electrónico resuelven la vidriera; el resto queda afuera.
Producto propio2026Ver el caso →
Software embebido
Destacado
La tarea que dejó de existir como tarea
Empresa de software embebido en hardware propioSoftware embebido
Cliente
Empresa de software embebido en hardware propio
Rubro
Software embebido
El problema
La gestión de débitos automáticos le llevaba al área de Administración unas cinco horas, dos veces por mes. Había que cruzar a mano varios archivos de planilla y corregir uno por uno los identificadores de cada punto de venta, porque el banco reconoce cada débito por una combinación exacta de CUIT, CBU y punto de venta: alcanzaba con que un cliente cambiara de cuenta o de titularidad para que la correspondencia dejara de cerrar.
Con cien clientes eso era un rato. Con más de dos mil eran unas 120 horas al año: tres semanas laborales enteras, todos los años, dedicadas a cruzar planillas.
Qué se construyó
Una aplicación web donde la administradora sube las planillas y, dos minutos después, recibe por correo los archivos listos para cargar en el sistema del banco y procesar el cobro.
Lo que hizo posible el reemplazo no fue programar: fue medir primero cuánto costaba realmente esa tarea. El problema nunca fue la administradora ni la planilla — era un procedimiento diseñado para un tamaño de empresa que había dejado de existir.
Los detalles que hacen la diferencia
El parche no falla el día que se pone
Falla el día que el negocio crece, y para entonces ya nadie recuerda que era un parche. La empresa había pasado de atender un centenar de clientes a más de dos mil: no se había roto nada, simplemente nadie volvió a mirar los procesos.
Rastrear el origen del pedido
Buena parte de los requerimientos que llegaban no eran necesidades nuevas: eran la consecuencia de parches acumulados años atrás. Rastrear ese origen es lo que casi nunca se hace, y es lo que evita automatizar el problema en lugar de resolverlo.
Cómo se verificó
La tarea dejó de existir. Medido en tiempo, unas 120 horas al año liberadas; medido en plata, una porción grande del sueldo de una persona que estaba destinada a una sola tarea que no le aportaba nada al negocio.
Stack
Automatización de procesos
Aplicación web
ISO 9001:2015
Testing QA
La gestión de débitos automáticos le llevaba al área de Administración unas cinco horas, dos veces por mes. Había que cruzar a mano varios archivos de planilla y corregir uno por uno los identificadores de cada punto de venta, porque el banco reconoce cada débito por una combinación exacta de CUIT, CBU y punto de venta: alcanzaba con que un cliente cambiara de cuenta o de titularidad para que la correspondencia dejara de cerrar.
Empresa de software embebido en hardware propioVer el caso →
Industria musical
Buddhabrot — identidad visual y sitio de un sello discográfico
BuddhabrotIndustria musical
Cliente
Buddhabrot
Rubro
Industria musical
El problema
Un sello discográfico con catálogo distribuido internacionalmente necesita que cada lanzamiento se reconozca como propio y que todo lo que se muestra afuera hable el mismo idioma visual.
Qué se construyó
Dirección de arte y diseño de la totalidad de las piezas: arte de tapa original para cada lanzamiento, diseñado pieza por pieza; piezas audiovisuales para redes y plataformas de difusión; y el diseño y desarrollo del sitio del sello.
Es el caso que muestra por qué producto, código, interfaz e imagen los cubre el mismo autor: no hay traspaso entre áreas ni ruido entre lo que se diseña y lo que se entrega.
Cómo se verificó
Catálogo publicado y distribuido internacionalmente, con identidad visual sostenida lanzamiento tras lanzamiento.
Stack
Adobe Photoshop
After Effects
Premiere Pro
Diseño web
Enlaces
Catálogo en Beatport
Sitio del sello
Un sello discográfico con catálogo distribuido internacionalmente necesita que cada lanzamiento se reconozca como propio y que todo lo que se muestra afuera hable el mismo idioma visual.
BuddhabrotVer el caso →
Educación y producción audiovisual
Gráficas en vivo sobre tres cámaras para una academia de cocina
Academia de cocinaEducación y producción audiovisual
Cliente
Academia de cocina
Rubro
Educación y producción audiovisual
El problema
Una academia de cocina filmaba sus clases con tres cámaras y necesitaba mostrar recetas y datos sobre la imagen, en vivo, mientras grababa.
Qué se construyó
Gráficas montadas como capas sobre la señal de las tres cámaras, construidas en HTML y CSS.
Es el primer trabajo donde esas dos tecnologías no sirvieron para hacer una página, sino para resolver un problema de producción en vivo. Ese sigue siendo el criterio: la herramienta se elige por el problema, no por costumbre.
Cómo se verificó
La academia pudo emitir recetas y datos sobre la imagen sin detener la grabación ni pasar por posproducción.
Stack
HTML
CSS
Producción audiovisual en vivo
Una academia de cocina filmaba sus clases con tres cámaras y necesitaba mostrar recetas y datos sobre la imagen, en vivo, mientras grababa.
Academia de cocinaVer el caso →

→

La pregunta difícil primero: ¿el mes pasado el negocio ganó plata, o parece que ganó?

Si la respuesta incomoda, hay una conversación de quince minutos que vale la pena. Se muestra el sistema funcionando sobre un negocio de demostración, y se relevan las cosas como se hacen hoy.

Escribir