Me incliné por el frontend desde temprano porque es la superficie donde la intención se encuentra con la realidad: los píxeles, la latencia, el texto y el flujo deciden si alguien sigue adelante o se va en silencio. Es un lugar humilde para trabajar: no puedes esconderte detrás de abstracciones cuando el usuario está mirando el resultado. Con el tiempo, ese instinto se convirtió en una lente reproducible: ¿qué trabajo está haciendo esta pantalla?, ¿qué restricción es innegociable? y ¿qué es el cambio más pequeño que podemos enviar que mejore mediblemente la confianza, la claridad o la velocidad? Todavía escribo UI, pero la pregunta detrás de la UI es lo que escala a través de equipos y productos.
En Luma Health pasé tiempo significativo dentro del Centro de Comunicación —un flujo de trabajo pesado y de alto tráfico donde el rendimiento y la claridad no son un mero pulido; son parte de la coordinación de la atención. El producto había acumulado capas de fricción en la experiencia del usuario y rutas de código heredadas que hacían que cada cambio pareciera riesgoso, lo cual es la forma en que los equipos se ralentizan sin darse cuenta. Ayudé a refactorizar esa superficie para que la experiencia se sintiera más ligera para los usuarios reales, y utilizamos canales de retroalimentación (incluyendo informes de usuarios) para validar que estábamos solucionando lo que la gente realmente sentía — no solo lo que era fácil de medir en un panel de control. De manera paralela, traté la seguridad como parte de la experiencia del usuario: el texto enriquecido generado por el usuario es un clásico problema de seguridad para XSS si solo se sanitiza “en alguna parte”. Ayudé a eliminar la exposición crítica mediante la sanitización de contenido antes del procesamiento de la API y nuevamente en los límites de renderizado, y contribuí a las API de componentes compartidos y a las decisiones del sistema de diseño para que otros equipos no tuvieran que redescubrir los mismos bordes afilados.
Parte de mi trabajo con mayor impacto se encuentra en donde se unen UX, comportamiento de backend y operaciones: donde una integración frágil se convierte en tickets, abandono o una página nocturna. Un ejemplo: una canalización de transmisión SFTP en la que "funciona en mi máquina" no fue suficiente para los clientes en flujos de datos sensibles. Lo rediseñé para que los equipos configuraran asignaciones de campos externos→internos en la IU con validación en lugar de adivinar y saturar el soporte. Los tickets de configuración incorrecta disminuyeron drásticamente y protegimos una relación que no podía permitirse traspasos descuidados. En Sisnet, trabajé en un mercado seleccionado donde la velocidad de contenido era tan importante como la calidad del código. Construí un CMS AdminJS en Node.js para que el marketing y las operaciones pudieran enviar contenido, imágenes y estilo sin necesidad de ingeniería para cada ajuste. Los simulacros semanales de emergencia se redujeron a "casi nunca", y el equipo pudo centrarse en las suscripciones, Stripe y Klaviyo, y en la profundidad del producto en lugar de la publicación rutinaria.
Fuera de mis roles a tiempo completo, co-fundé Membrus: una plataforma para que las iglesias gestionen membresía, comunicación y operaciones en un sistema coherente en lugar de un mosaico de hojas de cálculo, chats grupales y herramientas improvisadas. El trabajo no fue “agregar otra aplicación CRUD”. Se trataba de entender cómo los pastores y el personal realmente se mueven a través de una semana: quién necesita acceso a qué, qué se rompe cuando los datos son inconsistentes y cómo enviar flujos de trabajo administrativos que los no técnicos puedan poseer. Propiedad del producto y la entrega a través de superficies: presencia pública, experiencias orientadas a los miembros y herramientas internas, iterando con líderes de la iglesia que fueron generosos con comentarios honestos. Ese es el tipo de producto que quiero seguir construyendo: basado en limitaciones reales, entregado a usuarios reales, mejorado públicamente —no software de presentación.
En Shifting, trabajé en un equipo pequeño lanzando un mercado de boletos bajo una presión de alcance real: la velocidad importaba, pero también lo hacía no agotar a las personas. A menudo actué como la persona que tenía que elegir: qué cortar, qué fortalecer y qué negarse a comprometer. Mi sesgo estaba orientado hacia implementar bien, no de manera caótica: desbloqueo diario, revisión de código consistente para que la retroalimentación fuera predecible y pequeñas mejoras en la experiencia del desarrollador que hacían que la semana siguiente fuera más fácil que la anterior. También construí herramientas internas estilo CMS para que los compañeros no técnicos pudieran iterar contenido sin que la ingeniería se convirtiera en un cuello de botella. El resultado no fue solo “lo lanzamos”—fue un mercado funcional entregado a un ritmo sostenible, con un cliente que se sintió genuinamente bien atendido. Ese resultado es tan importante para mí como cualquier detalle técnico.
Este sitio es intencionalmente más que un currículum vitae estático. Es i18n-first, comparte la interfaz de usuario en todo el monorepo, y el diseño prioriza una jerarquía y espaciado legibles, de modo que páginas largas como esta sigan siendo agradables de leer. Lucas AI forma parte de la misma tesis: un asistente que responde en primera persona, pero solo desde un contexto estructurado publicado aquí —proyectos, experiencia y cómo pienso sobre las compensaciones— para que la exploración se sienta fundamentada en lugar de genérica. Si estás leyendo esto hasta aquí, estás viendo el argumento artesanal en miniatura: narrativa, sistemas y una superficie de producto que invita a la profundidad.
