← Volver al sitio

Archivo abierto / 11 PROYECTOS · 04 CATEGORÍAS

Lo que construí, y por qué.

Esto es todo lo que armé en los últimos años. Algunos shippean. Otros se murieron en el camino. Los dejo igual porque cada uno me enseñó algo. No es portfolio de venta — es cuaderno de trabajo.

/ Vertical SaaS

03 productos

Software a medida para industrias específicas. Build → deploy → soporte directo al cliente.

2025
  • SHIPPED
  • WIP

Sesión

SaaS de gestión para psicólogos independientes. Construido en 5 días durante el hackathon Kaszek × Anthropic 2025.

↳ 200/3000 builders · 5 días · $0.14 por paciente

  • SvelteKit
  • NestJS
  • PostgreSQL
  • Prisma
  • Tailwind
  • Claude Sonnet
  • Claude Opus

/ Por qué lo hice

Mi terapeuta me contó que pasaba 3 horas por semana cargando turnos, facturas y notas en cuatro herramientas distintas. Vi un vertical maduro sin SaaS argentino decente — los que existen son carísimos o están podridos por dentro. Cuando salió la convocatoria del hackathon Kaszek × Anthropic, fue la excusa: 5 días, deadline real, era ahora o nunca.

/ Decisiones técnicas

  1. 01
    SvelteKit sobre Next

    Necesitaba shippear UI completa en 48 horas sin ceremonias. La curva de Svelte es brutalmente más corta que la de Next + React Server Components. Para un solo dev contra reloj, la decisión era obvia.

  2. 02
    PostgreSQL + Prisma

    Ya conozco el stack. No podía permitirme debuggear Mongo aggregations a las 3 AM del día 4. Prisma me dio migrations versionadas y type-safety sin pensar.

  3. 03
    Claude Sonnet para ejecutar, Opus para asesorar

    Sonnet genera el resumen automático de sesión post-llamada (~1500 tokens, $0.14 por paciente/mes). Opus solo entra cuando la familia pide informe trimestral o aparece un caso clínicamente complejo. Patrón cheap-by-default, expensive-when-needed.

  4. 04
    Auth con magic link, sin OAuth social

    Psicólogos no quieren tracking cross-app de Google/Facebook adentro de la herramienta donde guardan notas clínicas. Email + magic link fue la respuesta correcta aunque agregó fricción al onboarding.

/ Lo que aprendí

  • Construir solo es 3x más rápido que tener equipo cuando el problema cabe en una cabeza. Comunicación tiene costo no-trivial.
  • Los hackathons valen: te dan deadline, validación social y un primer cliente (vos mismo) en el mismo plato.
  • El feature más usado (recordatorio de turno por SMS al paciente) lo agregué la última noche por aburrimiento. Lección: tirá ideas marginales si te quedan 2 horas libres — a veces son las que mueven el producto.
2024
  • SHIPPED
  • REVENUE

LocalCenter

Vertical SaaS B2B para comerciantes mayoristas en Argentina. 9 clientes pagos, 1 año en producción, integración AFIP completa (WSAA + WSFE).

↳ 9 clientes · 1 año en prod · AFIP WSAA + WSFE

  • Angular 17
  • NestJS
  • SQL Server
  • AFIP WSAA
  • AFIP WSFE
  • Tailwind
  • Angular Material

/ Por qué lo hice

Mi viejo tenía un negocio de venta mayorista y todos los sistemas que probó cobraban $200k ARS/mes o estaban podridos por dentro (UI de 2008, sin API, soporte por mail con respuesta de tres días). Le armé el mío. Después le dije «esto se puede vender» — y empezamos a venderlo de boca en boca. Hoy hay 9 clientes pagos y soy el único developer, soporte y customer success del producto.

/ Decisiones técnicas

  1. 01
    SQL Server sobre Postgres

    Los clientes de mi viejo ya usaban Excel + Office y vivían en el ecosistema Microsoft. Reducir fricción cultural era más importante que el «mejor stack». Cuando el cliente necesita un export, sale directo a .xlsx sin convertir nada.

  2. 02
    Angular 17 con Material

    Tenía componentes Angular Material reutilizables de otro proyecto. La velocidad de empezar pesó más que la pureza del framework. En 2 semanas tenía CRUD de productos, clientes, facturas y stock funcionando.

  3. 03
    AFIP: cola Redis con retry exponencial

    La integración con AFIP (WSAA + WSFE) es lo más doloroso del producto. Tickets de acceso que vencen cada 12 horas, rate limits agresivos (3 req/s), errores 8001 sin documentar. Resolución: cola Redis que guarda cada facturación pendiente y reintenta con backoff exponencial. Si AFIP está caído, el cliente factura igual y el sistema sync cuando vuelve.

  4. 04
    Hosting propio en VPS argentino

    AWS hubiera sido más caro y más lento para mis clientes. El VPS en Buenos Aires da latencia <30ms para todos. Compliance argentino también es más simple (los datos no salen del país).

  5. 05
    Soporte directo, yo atiendo los tickets

    No hay nivel 1 ni chatbot. Saco más insight de una call de 15 minutos con un cliente real que de 100 surveys. El 70% de las features del último año salieron de problemas que vi en soporte.

/ Lo que aprendí

  • Vender lo que ya construiste es 10x más fácil que vender lo que vas a construir. Tener el primer cliente (mi viejo) cubierto eliminó toda la presión de validation.
  • Los clientes argentinos quieren WhatsApp, no chat web. Aprendido tras 6 meses de silencio total en mi chat de soporte web — el día que activé WhatsApp Business, recibí 12 mensajes en la primera hora.
  • Un vertical aburrido (mayoreo de electrónica) con margen alto y churn bajo vence a un vertical sexy (AI startup B2C) con métricas vanity y churn del 8% mensual. Mayoristas no se mudan de sistema fácil.
2026
  • SHIPPED

balanza-agent

App de escritorio (Tauri, Rust + JS) que conecta balanzas Kretz al sistema LocalCenter. v1.1.4 en producción. Companion del producto principal.

  • Tauri 2
  • Rust
  • TypeScript
  • Kretz protocol
Ver detalle

/ Por qué lo hice

Mis clientes de LocalCenter venden por peso (cables, varillas, materiales eléctricos). Cada balanza Kretz tiene su protocolo serial propio. Sin integración, el operario lee la balanza con el ojo y escribe el número a mano — error humano garantizado. El balanza-agent lee la balanza por USB y manda el peso al sistema sin tocar el teclado.

/ Decisiones técnicas

  1. 01
    Tauri sobre Electron

    Electron pesaba 200MB y los clientes corren Windows viejos en máquinas modestas. Tauri pesa 12MB y abre instantáneo. Para una app companion que no necesita un browser engine, fue obvia.

  2. 02
    Protocolo Kretz documentado a mano

    Kretz no publica spec. Lo hice por reverse engineering con un osciloscopio USB y dos horas de paciencia. Documenté el protocolo en kretz-protocol/ por si algún día alguien más lo necesita.

/ Lo que aprendí

  • Hardware integration es 80% paciencia + 20% código. El día que la balanza «no respondía» era un cable USB roto.
  • Apps companion son una way undervalued de extender un SaaS. Para los clientes, el balanza-agent vale tanto como toda la app principal.

/ Sistemas IA / Agentes

04 sistemas

Agentes autónomos que ejecutan trabajo. Orchestration, RAG, multi-agent.

2024 — presente
  • WIP
  • LAB

JARVIS

Sistema multi-máquina para orquestar agentes Claude Code en mi setup local. Cuatro máquinas, cuatro cuentas, un solo cerebro.

  • Bash
  • Node.js
  • tmux
  • SSH
  • Tailscale
  • Claude Code SDK
  • +1
Ver detalle

/ Por qué lo hice

Cuando empecé a usar Claude Code en serio me di cuenta que en un día llenaba el context window de una sola cuenta. La solución obvia (pagar más) no resolvía el cuello de botella real: yo no podía pensar en cuatro problemas simultáneos. JARVIS es el sistema que arma cuatro agentes paralelos, cada uno con su cuenta, atacando partes distintas del mismo problema, y los sincroniza al final de cada ronda.

/ Decisiones técnicas

  1. 01
    Tailscale como mesh VPN

    Las cuatro máquinas viven en redes distintas (casa, oficina, móvil). Setear OpenVPN o WireGuard manual fue lo primero que intenté — perdí 2 días. Tailscale resolvió todo en 15 minutos. Lección: usar la herramienta correcta cuando existe.

  2. 02
    tmux como UI

    No quería construir un frontend web cuando una grilla de 4 paneles tmux ya hace el trabajo. Cada panel = una máquina + agente. Status bar tmux muestra carga, latencia y cuenta activa. Sin polish, full information density.

  3. 03
    Bash + Node para orquestación

    Python hubiera sido más limpio pero menos portable (NOMAD es Windows con WSL). Bash + node es el mínimo común denominador. Toda la lógica de paralelización vive en ~/jarvis-parallel.sh, 200 líneas de bash que entiendo de memoria.

  4. 04
    Roles fijos por máquina

    ATLAS (Mac Mini M4 Pro) = orquestador. NOVA (i5 + RTX 3060, Windows) = backend Node. PIXEL (Ryzen + RTX 3070, Pop!_OS) = frontend + GPU heavy. NOMAD (laptop Ryzen 7) = mobile + respaldo. Cada máquina aporta lo que mejor hace, el orquestador hace match-making.

/ Lo que aprendí

  • Las herramientas que construís para vos mismo son las que mejor entendés. Si algún día productizo JARVIS, será con conocimiento de uso real, no specs de mercado.
  • SSH stdin keepalive es un mundo aparte. Aprendí más bash en dos semanas de JARVIS que en cinco años programando. Cuando un sistema falla en silencio, es donde más se aprende.
  • El context window es un cuello de botella real, no inventado. La gente que use Claude Code 10hrs/día va a llegar a esta conclusión sola. Una versión cleaned-up de JARVIS podría ser producto, pero todavía es muy mío.
2026
  • WIP

Agentingk

Sistema multi-tenant de operadores IA conversacionales sobre WhatsApp. Multi-línea, anti-ban, handover humano, failover a WABA oficial. Reemplaza operadores en contact centers.

  • TypeScript
  • Turborepo
  • Fastify 5
  • Next.js 15
  • Postgres + pgvector
  • Redis + BullMQ
  • +4
Ver detalle

/ Por qué lo hice

La mayoría de las empresas argentinas que venden por WhatsApp lo hacen con operadores humanos sentados frente a Chrome todo el día. El costo es alto, la rotación es brutal y la calidad es desigual. Lo que la IA hace bien hoy (atender consultas estándar, calificar leads, dar info de producto) cubre buena parte del trabajo. Agentingk apunta a ese trabajo y deja el resto al humano via handover.

/ Decisiones técnicas

  1. 01
    Monorepo con apps + packages estrictos

    Turborepo con tres apps (dashboard Next 15, orchestrator Fastify, worker Node) y siete packages (ai-engine, rag, wa-providers, human-emulation, db, config, shared). TypeScript estricto con exactOptionalPropertyTypes y noUncheckedIndexedAccess. Es el nivel de rigor que hace falta cuando el sistema tiene que correr 24/7.

  2. 02
    Adapter pattern para proveedores WhatsApp

    BaileysProvider por defecto (gratis), OpenWAProvider como alternativa, WhatsAppBusinessAPIProvider para failover oficial. Si Meta cierra un número, el sistema migra solo al canal oficial. Es la única forma de operar con confianza al lado de un canal hostil al automation.

  3. 03
    LLM router cascada por costo

    Groq Llama 3.3 como default ($0.05/M tokens). Claude Haiku para queries que requieren context más largo. Sonnet solo en triggers críticos (escalation, leads grandes, complaints). El cost-per-message importa cuando manejás miles de chats simultáneos.

  4. 04
    Human emulation explícita

    Package human-emulation con delays gaussianos, typing indicators, message splits y warm-up limits. WhatsApp banea cuentas que se comportan «demasiado bien». La IA tiene que escribir como humano cansado, no como GPT-4 perfecto.

/ Lo que aprendí

  • Operar sobre canales hostiles (Baileys + WhatsApp no oficial) es una guerra constante. El failover a WABA no es opcional — es el plan B obligatorio.
  • Multi-tenant es 4x más difícil que single-tenant. Cada cliente tiene su KB, sus líneas, sus operadores, sus prompts. Si no tenés isolation buena, un error rompe todo.
  • RAG híbrido (vector + tsvector) supera a vector puro en español argentino. Las consultas tipo «cuanto cuesta el caño de 1/2 cromado» mezclan substring matching con embeddings.
2026
  • IDEA
  • LAB

Mendr

El bug entra a Sentry → sale como pull request. Auto-fix de bugs en producción con Claude SDK. 5 niveles de autonomía: desde comentario hasta push directo en hotfix.

  • Claude Agent SDK
  • Next.js
  • Redis + BullMQ
  • GitHub API
  • Sentry webhook
Ver detalle

/ Por qué lo hice

Cada equipo tiene un on-call que se despierta a las 3 AM por bugs que se podrían arreglar con 10 líneas de código. El 70% son bugs de regresión que el agente puede diagnosticar mejor que un humano dormido. Mendr es la idea: el primer line of defense de tu on-call es una IA.

/ Decisiones técnicas

  1. 01
    5 niveles de autonomía como contrato

    Nivel 0: comentario en Sentry. Nivel 1: PR draft. Nivel 2: PR + tests verdes. Nivel 3: PR auto-merge si bajo riesgo. Nivel 4: push directo a hotfix branch. El equipo elige el nivel por repo. La confianza se gana, no se asume.

  2. 02
    Claude Agent SDK como runtime

    El agente clona el repo, lee el stack trace, identifica el archivo culpable, propone un fix y corre los tests. Sandbox por tenant. Sin output streamed al cliente — el agente trabaja en silencio y entrega el resultado.

/ Lo que aprendí

  • La idea nació mirando errores recurrentes de AFIP en LocalCenter — los mismos patrones de bug ocurriendo de noche y resolviéndose en 10 minutos a la mañana. Si un agente puede ver el patrón, debería poder proponer el fix.
  • Ideas que se construyen para vos mismo son las que mejor entendés. Mendr nace de mi frustración operando productos, no de un pitch deck.
2026
  • LAB
  • OPEN SOURCE

lightrag-mcp

MCP server para LightRAG. Conecta Claude Code a un knowledge graph + vector store unificado. Python 3.13, voyage AI embeddings, Anthropic API.

  • Python 3.13
  • LightRAG
  • MCP
  • voyageai
  • Anthropic
Ver detalle

/ Por qué lo hice

LightRAG es un graph-based RAG que combina knowledge graph + dense retrieval. Es mejor que vector-puro para queries que requieren múltiples hops. Quería usarlo desde Claude Code sin levantar un servidor HTTP custom — MCP es el canal correcto.

/ Decisiones técnicas

  1. 01
    MCP como capa de adapter

    MCP estandariza el contrato entre el agente y la fuente de datos. Cualquier MCP client (Claude Code, Cline, Zed) puede usar este server. Reuso > custom.

/ Lo que aprendí

  • Los protocolos abiertos como MCP eliminan trabajo. Si un protocolo existe y funciona, el costo de adoptarlo siempre vale.

/ Trading Cuantitativo

02 sistemas

Sistemas quant en mercados de predicción. Multi-strategy, defensive safeguards.

2026
  • SHIPPED
  • WIP

atlas-fleet

Flota de 13 trading bots con nombres Marvel sobre Polymarket. Multi-strategy: weather ensemble, bonds, market making, whale-copy, contrarian, arbitrage Polymarket vs Kalshi. V2.0 con circuit breakers, atomic state y heartbeats.

↳ 13 bots · Avellaneda-Stoikov MM · circuit breakers · v2.0

  • Node.js
  • Polymarket CLOB
  • WebSocket
  • Claude
  • Telegram
  • Docker
  • PM2
Ver detalle

/ Por qué lo hice

Los mercados de predicción son uno de los pocos lugares donde un retail tiene edge si pone trabajo. Polymarket en particular tiene libros líquidos, fees bajos y una superficie de información gigante que las casas grandes no miran. Lo que arranqué como un script de 200 líneas terminó siendo una flota de bots especializados — cada uno con su rol claro — porque resolver «predicción + ejecución + riesgo + arbitraje» con un solo agente es engineering malo.

/ Decisiones técnicas

  1. 01
    Naming Marvel + roles fijos

    Cada bot tiene un nombre Marvel y un rol único. TONY orquesta. JARVIS escanea news (RSS, Reddit, Twitter, CoinGecko). FRIDAY mira WebSocket prices + whales. VISION aprende y genera wisdom. XAVIER coachea a cada bot. STEVE corre weather ensemble (GFS/ICON/ECMWF). REED juega bonds (compra cerca-certeza a 93-99c). QUILL hace market making con Avellaneda-Stoikov. STRANGE arbitraje Polymarket vs Kalshi. Los nombres no son cosméticos — me obligan a separar responsabilidades.

  2. 02
    RiskManager con state atómico

    Drawdown limits, correlación entre posiciones, circuit breakers per-domain (CLOSED → OPEN → HALF_OPEN como Hystrix). El RiskManager es la única forma de tocar capital. Si la máquina muere mid-trade, write→verify→rename garantiza que no quede en estado inconsistente.

  3. 03
    Heartbeat + preflight

    Cada bot manda heartbeat al orchestrator. Si uno muere, TONY lo restarta. Antes de cualquier launch, preflight valida env vars, disk space, red, dependencias. Aprendí construyendo esto: un sistema que no se mata solo se muere sucio.

  4. 04
    Telegram para todo el monitoring

    Cero dashboard al principio. Solo Telegram bot (@atlas_fleet_lauti_bot) que tira eventos críticos: fills, drawdowns, circuit-breaks. Mucho más eficiente que abrir 5 pestañas a las 3 AM cuando algo se prende fuego.

/ Lo que aprendí

  • Separar bots por rol único es 5x más fácil de razonar que un super-agente. La regla: si dos bots se comunican mucho, probablemente son uno solo.
  • Defensive programming no es opcional cuando hay plata real en juego. Atomic state, circuit breakers y preflight no son sobrecarga — son las únicas razones por las que el sistema corre sin supervisión.
  • Los nombres importan. El día que renombré PEPPER (stocks ARG/MERVAL) le entendí el rol. Antes era «el bot del mercado argentino» y no terminaba de cuajar.
2026
  • WIP

atlas-fleet-nautilus

Port de atlas-fleet a NautilusTrader (Python). 1935 tests, 81.63% coverage, mypy clean, ruff clean. 3 strategies activas, 5 safeguards production-grade.

  • Python 3.13
  • NautilusTrader
  • uv
  • pytest
  • mypy
  • +1
Ver detalle

/ Por qué lo hice

JS está bien para prototypear pero NautilusTrader es la única plataforma open-source seria para event-driven trading. Type safety total, backtest determinista, paper/live con la misma codebase. Migrar atlas-fleet a NautilusTrader es el siguiente paso para que el sistema sea defensible.

/ Decisiones técnicas

  1. 01
    5 safeguards de defense-in-depth

    Wallet spend caps, circuit breaker, pre-submit simulation, deadline enforcement y isolated private-key handling. Live mode está detrás de un flag y dormant hasta que el operador firme kernel-validation.

  2. 02
    Coverage como contrato

    1935 tests no son ego — son la única forma de migrar sin destruir el legacy. Cada strategy del JS tiene un test golden que matchea outputs antes/después. Si rompo algo, sé exactamente qué.

/ Lo que aprendí

  • Migrar es 3x más difícil que construir. Cada decisión vieja tiene un por qué que descubrís mid-port.
  • El test suite es lo más caro y lo más valioso. Sin él, no me animaba a tocar nada.

/ Herramientas R&D

02 experimentos

Experimentos, design tools, visión computacional. Lo que pruebo cuando no tengo cliente.

2026
  • IDEA
  • WIP

Lume

«Diseñá webs como en Canva. Publicá código como un senior.» Multi-Modal Generative Web Design (MMGD). Conversación con IA + edición visual → código limpio Astro/Next + Tailwind.

↳ PRD completo · 7 docs · prototype Next.js

  • Next.js
  • Astro
  • Tailwind v4
  • Claude / GPT
  • TipTap-like editor
Ver detalle

/ Por qué lo hice

Hoy el usuario no-técnico que quiere una web está atrapado entre dos malas opciones: Webflow/Canva (output limitado, lock-in) o contratar a un dev (lento, caro). Las herramientas «no-code» nunca generan código que un humano quiera tocar. Lume apunta al medio: vos describís en español lo que querés, la IA propone, vos editás visualmente, y al final salís con un repo Git que un dev puede mantener.

/ Decisiones técnicas

  1. 01
    MMGD: metodología propia

    Multi-Modal Generative Web Design separa intent (qué querés) de form (cómo se ve) y emite tres outputs: design tokens, componentes Astro/Next, y un PRD reusable. La separación es lo que permite que el código sea limpio en vez de gobbledygook generado por LLM.

  2. 02
    Output target: Astro/Next + Tailwind

    No HTML estático, no «exportar a Wix». Repos reales con package.json, CI/CD listo, deploy a Vercel/Netlify. Si la IA no genera código que vos tocarías, es ruido.

  3. 03
    Editor visual sobre el AST, no sobre el DOM

    Cuando el usuario arrastra un componente, edita el AST de Astro y regenera el código. No se inyecta CSS inline. El resultado es código que parece escrito por un humano.

/ Lo que aprendí

  • Escribir el PRD entero antes de tirar una línea de código duele pero salva meses. Ya tengo claro qué problemas son del MVP y cuáles del v2.
  • Las metodologías propias (MMGD) son una herramienta de pensamiento, no marketing. Me ayudan a defender decisiones cuando viene la presión de «hacer lo que hace Framer».
2026
  • LAB

fb-marketplace-search

Scraping de FB Marketplace + ranking visual con CLIP embeddings locales (MPS / CUDA / CPU). Buscás «membrana de caucho» y te ordena los listings por similitud visual contra una imagen tuya.

  • Python
  • Apify
  • CLIP
  • FastAPI
  • Vite
  • +2
Ver detalle

/ Por qué lo hice

Buscar materiales específicos en FB Marketplace es horrible: el algoritmo te muestra cosas tangenciales, los títulos mienten, y no podés filtrar por «se parece a esto». Lo armé porque necesitaba encontrar exactamente una membrana de caucho y FB me devolvía neumáticos. Cinco horas después funcionaba.

/ Decisiones técnicas

  1. 01
    CLIP local en lugar de API

    Embeddings de OpenAI cuestan dinero y son lentos por la red. CLIP corre local en Apple Silicon (MPS) en 200ms por imagen. Una vez calculados los embeddings, el ranking es coseno puro.

/ Lo que aprendí

  • Las herramientas que armás para resolver un problema propio son las que mejor terminás. No tenía cliente, solo necesidad.
  • CLIP es absurdamente útil para casi cualquier task de visual similarity. Si tu producto involucra imágenes, debería estar en tu stack.

Cómo pienso / PRINCIPLES

Cinco principios que aplico.

No son axiomas. Son cosas que aprendí construyendo, fallando y matando proyectos. Cada uno con su factura.

  1. / 01

    Empezá con datos reales antes que con UI.

    Diseñé pantallas durante un día entero antes de saber si la API daba la data que necesitaba. No daba. Tuve que rediseñar todo. Ahora: data y endpoints primero, UI después.

    Sesión
  2. / 02

    El vertical aburrido > el vertical sexy.

    Mayoristas argentinos no son tema de pitch deck. Pero pagan a tiempo, no se mudan de sistema, y un bug bien arreglado te genera lealtad por dos años. Lo aprendí con LocalCenter.

    LocalCenter
  3. / 03

    Construí solo hasta que no podás.

    Cuando el problema cabe en una cabeza, el equipo es overhead. JARVIS funciona porque soy yo decidiendo todo. Sumo gente cuando el cuello de botella es velocidad, no cuando es ego.

    JARVIS
  4. / 04

    Matar es más difícil que construir.

    Cada proyecto muerto me costó meses. La señal para matar nunca es ruidosa — es ausencia: silencio del cliente, falta de ganas de tocar el código, métricas que mentís en una conversación. Cuando aparece, matá.

  5. / 05

    El cliente no quiere features, quiere que el problema desaparezca.

    Agregué 12 reportes en Excel a LocalCenter que nadie usaba mientras el cliente solo quería que «deje de tirar error 8001 cuando facturo». Una hora arreglando ese error movió más que tres meses de features nuevas.

    LocalCenter

Si algo de esto te resonó, escribime.

Hablemos →