Hola, soy Joaquin Mellado
Ingeniero de Software Senior Full-Stack construyendo productos confiables con IA usando React, TypeScript, Python e infraestructura en la nube.
Software Engineer con mentalidad de producto
Conecto software engineering, criterio de producto, craft frontend y flujos prácticos con IA para construir cosas que la gente pueda entender, confiar y usar.
Trabajos destacados
Estoy preparando casos de estudio concisos sobre la arquitectura, decisiones, tradeoffs y resultados detrás de los productos que he construido. Cada caso mostrará problemas reales, código real y resultados reales.
Un asistente de investigación con IA para inversores de dividendos que combina flujos de datos financieros, análisis de riesgo multiagente, RAG sobre documentos de la SEC y simulaciones explicables de investigación de portafolios con controles de cumplimiento.
Herramienta educativa de investigación — no es asesoramiento financiero.
Stack tecnológico
Flujo de arquitectura
Por qué ahora
La IA hace más fácil generar interfaces, features y código. Eso vuelve el criterio más valioso, no menos. La ventaja real está en saber qué debería existir, qué debería eliminarse, qué medir y dónde el producto realmente está fallando.
La IA puede acelerar producción, pero también multiplicar ideas débiles, flujos confusos e interfaces olvidables.
Velocidad, claridad, accesibilidad y confiabilidad construyen confianza antes que un roadmap o una lista de features.
Las decisiones técnicas definen qué tan seguro es cambiar, aprender y entregar sin crear arrastre invisible.
Los buenos equipos usan comportamiento, fricción, retención y feedback para decidir qué construir después.
Lo que realmente he aprendido
He trabajado en banca, plataformas frontend a escala, workflows internos de riesgo y un MVP que fundé. Contextos distintos, misma lección: la calidad de software importa cuando ayuda a las personas a avanzar.
Error rate, LCP, abandonos, flujos lentos, señales de soporte y datos de observabilidad suelen decir más que una demo pulida.
Adobe, Datadog y métricas de plataforma no son solo dashboards de ingeniería. Pueden mostrar si el producto realmente está funcionando para las personas.
Microfrontends, paquetes compartidos y límites modulares solo ayudan cuando el ownership y los patrones de cambio están claros.
Siempre estoy buscando oportunidades para emprender, probar productos y aprender de usuarios reales. Probablemente es el mejor momento que hemos tenido para hacerlo.
Lo que me preocupa
Hacer buen software es la base. La pregunta difícil es si el producto crea valor, cambia comportamiento, gana confianza y se mantiene sano mientras avanza rápido.
¿La gente va a recordar esta experiencia o es solo otra interfaz más?
¿Estamos resolviendo un problema doloroso o solo enviando actividad visible?
¿Qué hace, repite, evita o abandona realmente el usuario?
¿La IA mejora criterio y velocidad, o solo aumenta volumen de output?
¿El producto se siente rápido, claro, accesible y confiable?
¿Avanzamos rápido sin crear arrastre invisible para el equipo?
Señales que busco
La gente vuelve porque el producto resuelve algo que importa.
La experiencia sigue produciendo valor después de la primera visita.
Confusión, dudas, pasos repetidos y abandono se convierten en input de diseño.
La velocidad se vuelve parte de la confianza, conversión y calidad percibida.
El equipo se alinea alrededor de valor, no de dashboards de vanidad.
Los tradeoffs son explícitos, intencionales y visibles antes de volverse arrastre.
Trampas que evito
Más features pueden hacer que el producto sea menos memorable.
Números que se ven bien pueden esconder aprendizaje débil.
Una UI limpia puede esconder decisiones caras y costo futuro de mantención.
Ciclos largos de feedback debilitan criterio de producto y calidad de entrega.
Product OS
Trabajo desde la ambigüedad hasta comportamiento en producción usando un loop simple: descubrir, dar forma, construir, medir e iterar.
Ver cómo construyoNotas de campo
Las mejores decisiones frontend rara vez son solo técnicas. Afectan autonomía de equipos, velocidad de entrega, riesgo de producto y el costo de cambiar después.
Tradeoffs de arquitectura
En sistemas frontend grandes, he visto cómo las decisiones de arquitectura afectan qué tan seguro es entregar, qué tan independiente puede trabajar cada equipo y qué tan caros se vuelven los cambios de producto. Microfrontends, module federation, librerías compartidas y monolitos modulares no son niveles de madurez. Son tradeoffs.
Más autonomía para equipos, pero más complejidad operacional e integración.
Composición flexible en runtime, pero debugging, versionado y ownership más difíciles.
Más consistencia y reutilización, pero posibles bloqueos de release y acoplamiento.
Entrega más simple, pero necesita límites fuertes para evitar entropía lenta.
La mejor arquitectura es la que calza con el ritmo de cambio del producto, la estructura del equipo, el perfil de riesgo y la necesidad de aprender rápido.
Transfers, onboarding y gestión de cuentas me enseñaron que confiabilidad, claridad y performance son features de producto, no detalles de ingeniería.
Construir BinnApp desde idea hasta MVP me enseñó a reducir alcance, coordinar discovery y tomar decisiones técnicas bajo incertidumbre.
Proof of craft
El juego de Signal no es decoración. Es una pequeña metáfora de cómo construyo: identificar señales valiosas, evitar trampas caras, avanzar con intención y desbloquear mejores decisiones.
Si así diseño una interacción de portfolio, imagina cómo abordo flujos reales de producto.
Cuándo puedo ayudar
Trabajo mejor cuando hay algo real que resolver: qué construir, qué simplificar, qué se está rompiendo y cómo entregar sin esconder costo futuro.
Puedo ayudar a convertir ambigüedad en flujos, decisiones y comportamiento en producción.
Miro arquitectura, performance, claridad UX y mantenibilidad como partes del mismo problema.
Me importa entregar, pero también sacar trabajo que no ayuda a las personas a avanzar.
Trabajemos
Si tu producto necesita mejores decisiones, más calidad frontend o ejecución consciente de IA, hablemos.