Tech Lead · Desarrollador Full Stack
Desarrollador full stack con 5 años construyendo productos web de punta a punta. He liderado equipos pequeños como tech lead: decisiones de arquitectura, stack y estándares, y metiéndome en la lógica de negocio cuando el equipo no tenía un rol de producto dedicado.
Mi criterio por defecto es la opción más simple que resuelva el problema real — no la más completa. Y creo que hoy, con IA en el flujo de trabajo (Claude Code y modelos locales con Qwen), lo técnico dejó de ser la barrera: el foco está en las soluciones y en las personas que las construyen.
Doble nacionalidad boliviana y peruana — puedo trabajar en ambos países.
Principios
Cuando hay dos caminos, el que gana no es el más elegante sino el que menos riesgo y menos costo mete al negocio. Migrar una base entera puede ser lo «correcto»; un adapter que la puentea puede ser lo que mantiene el producto vivo. Decido con ese lente y lo dejo escrito para que el equipo sepa por qué.
Cuando negocio pide algo y el equipo lo sobredimensiona, no aprieto al equipo — la moral y el estrés son parte del sistema. Primero valido con el equipo si el requerimiento está realmente sobredimensionado, después medio con negocio para recortarlo a un MVP, lo medimos, y recién con esos datos re-estimamos tiempo e infraestructura para el resto.
Uso Claude Code y modelos locales (Qwen) donde más rinden: explorar sistemas que no conozco, debugging y revisión de código. En Q-minex llegaron máquinas de minado de un modelo nuevo; con acceso SSH desde la red de planta usé IA para mapear el firmware y las APIs expuestas, y de ahí salió la propuesta de integración y el factory que las sumó al sistema — días de discovery reducidos a horas.
Herramientas
Dinero moviéndose de punta a punta
Implementación end-to-end de Stripe en Racquets App Suite para cobros de inscripción a torneos, reserva de canchas y sesiones de entrenamiento. En Q-minex, integración con Binance para controlar el depósito de los ASICs a la cuenta principal y automatizar los depósitos del saldo generado. Formación en la API de facturación electrónica de Bolivia.
Trayectoria
Parte del núcleo técnico de una startup de 8 personas, liderando un equipo de tres (dos desarrolladores y una diseñadora) para construir una plataforma de gestión de criptomonedas y control remoto de equipos de minería, distribuidos en 3 plantas con 111 rigs activos y capacidad física para 500. Tomé todas las decisiones de arquitectura del producto y llegamos al primer despliegue en producción en 5 meses.
Único responsable del backend y la infraestructura de una plataforma inmobiliaria (inmobile-app.com) donde los agentes gestionan sus propiedades y obtienen matches con listados relevantes. Construí todo el backend en Go y me encargué de la escalabilidad de punta a punta. Las implementaciones están terminadas y el producto está en beta abierta en Google Play: con los primeros usuarios y los dashboards funcionando mientras se prepara el lanzamiento.
Único desarrollador del sistema que reemplazó la plataforma propia heredada —una caja negra sin documentación ni visibilidad— de una distribuidora de bibliografía académica de la Zona Andina (180.000+ títulos). Lo construí solo en 3 meses: un sitio institucional público con catálogo de libros y un panel administrativo con login para catálogo, clientes y facturación.
Lideré el frontend de una plataforma de ecommerce B2C de productos no perecederos, llevándola de cero a producción en 8 meses con un desarrollador a mi cargo. Reemplazó una tienda previa en Shopify que ya tenía tráfico en toda Bolivia, así que la reconstrucción tenía que sostener esa audiencia y a la vez levantar los límites que la plataforma anterior le imponía al negocio. Definí la arquitectura, el stack (Next.js), los estándares de código y las decisiones de diseño.
Único desarrollador del sitio de una cafetería (lalalattecoffee.com): una vitrina de productos con CMS propio para que los dueños publiquen promociones y gestionen el contenido por su cuenta. Construido en menos de un mes y sigue vigente en producción.
Tech lead de una plataforma para deportes de raqueta (reserva de canchas y torneos). Lideré tanto la app móvil en React Native como el backend en Node.js, coordiné un equipo de ~5 desarrolladores y trabajé directamente con el CEO para planificar e implementar nuevas features. Cuando entré, el producto tenía dos módulos (reserva de canchas y torneos simples); lideré el diseño y desarrollo de los módulos de torneos y academia para escalarlo a más usos. Funcionó en producción con 5 clubes y alrededor de 200 jugadores.
Segundo frontend (y quinto desarrollador en total) en unirme a una startup de logística enfocada en transporte de carga, que conecta empresas con conductores y camiones. Durante 2.5 años acompañé el crecimiento de la empresa de 5 a ~50 personas, trabajando en tres productos sucesivos: FMS, TMS y el marketplace que conecta carga con flotas y camiones.
En la práctica
Racquets App Suite · 2022
Entré a liderar una suite deportiva que ya estaba en producción sobre Firebase. Al crecer la complejidad se decidió pasar a una base relacional, y quedaban dos caminos: migrar todos los módulos anteriores, o escribir un adapter que dejara a los módulos viejos hablar con la base nueva.
Elegí el adapter. La migración completa significaba más tiempo, más costo y un riesgo real de romper funcionalidad que ya estaba dando servicio a usuarios. El adapter dejó al equipo construir los módulos nuevos sobre la base correcta desde el día uno, sin congelar el producto. La deuda quedó acotada y visible, que es distinto a no tenerla.
Gaia del Sur · 2025–2026
Gaia funcionaba sobre una plataforma propia heredada de un equipo anterior: sin documentación, sin visibilidad de lo que hacía con los datos del propio negocio y sin nada que se pudiera tocar con seguridad. Reemplazarla era la decisión fácil. Sacar los datos no lo era: el catálogo de 180.000+ títulos solo existía dentro de ese sistema, sin exportación y sin un esquema que alguien pudiera leer.
Volver a cargarlo a mano nunca fue una opción real, y tampoco había una vía confiable hacia la base de datos por debajo. La única interfaz que el sistema viejo seguía respetando era la suya: todavía sabía mostrar cada registro en pantalla. Así que escribí un scraper en Playwright que recorrió el catálogo como lo haría un usuario, y normalicé lo que volvía en el nuevo modelo de PostgreSQL. Scrapear suele ser un olor a problema; acá fue la salida más barata y honesta de un sistema que nadie podía leer. El objetivo del proyecto nunca fueron funcionalidades nuevas: fue volver legibles los datos para el negocio que era su dueño.
Q-minex · 2026
Llegaron ASICs de un modelo que el sistema no soportaba. Los conectamos a la red de la planta y, con acceso SSH, usé IA para explorar el equipo: qué firmware corría, qué APIs exponía, qué formato devolvía cada endpoint. Con ese mapa armamos la propuesta de integración y construí el factory para ese modelo, ya listo para entrar al pipeline de minería junto a los 111 rigs activos.
Lo interesante no es que la IA escribió código — es que comprimió la parte más lenta, que era entender un sistema cerrado del que no teníamos documentación.
Inmobile · 2026
Inmobile cruza lo que los agentes publican contra lo que los compradores buscan — un patrón de búsqueda no es más que una publicación con otro estado. Puse el matching en un Cloudflare Worker con su propio cron, separado del backend en Go, para que una pasada de scoring lenta nunca pudiera volver lenta una request a la API.
El cursor fue lo que más tiempo llevó. Lo obvio —guardar el último timestamp procesado y seguir desde ahí— pierde filas en silencio, porque NOW() de Postgres es estable dentro de una transacción: un update masivo deja miles de filas con exactamente el mismo valor, y cualquier batch que corte ese grupo se come el resto. Pasé a un cursor keyset sobre (touched_at, id) que solo avanza cuando el batch terminó de escribirse, así una corrida que muere a la mitad simplemente reprocesa de forma idempotente. El scoring además corre íntegro desde caches en memoria, porque en Workers cada lookup extra es un subrequest, y ese límite es el que decide si podés comparar una publicación contra todo el catálogo o solo contra un puñado.
Producto propio · 2026
Construí un SaaS multi-tenant sobre un backend gestionado y después lo migré a PostgreSQL self-hosted. El servicio gestionado fue la forma correcta de arrancar —me ahorró una semana de setup que no necesitaba hacer dos veces— pero a medida que el producto creció, las piezas que más necesitaba controlar, la autenticación y las políticas de la base, eran las que menos controlaba. Así que hice la migración, y agregué un chequeo en CI que rompe el build si reaparece una referencia al proveedor viejo. Una migración que nadie hace cumplir es apenas una limpieza que alguien va a deshacer en silencio.
La decisión más interesante fue qué la reemplazó. El aislamiento entre inquilinos dejó de ser un filtro por organization_id escrito a mano en el código de aplicación y pasó a ser Row-Level Security de Postgres, con cada query corriendo dentro de una transacción que fija el inquilino de esa sesión. El punto no es que RLS sea más sofisticado — es que ahora el límite falla cerrado: un desarrollador que se olvida del filtro no obtiene filas, en vez de obtener las de otro. Para que eso siga siendo cierto, cada migración que crea una tabla de inquilino tiene que traer su propia política, y un script en CI rompe el build cuando alguna no la trae.
Formación
En la etapa final de mi carrera de Ingeniería de Sistemas, con el proyecto de tesis como requisito pendiente. También fui voluntario en la sociedad científica estudiantil de la universidad, donde contribuí a proyectos y enseñé tecnologías web a los nuevos miembros.
Construyamos
Abierto a roles de tech lead y full stack: remoto con solape completo con husos horarios de EE.UU., presencial o híbrido en Cochabamba, y contratación formal en Perú. Estoy abierto a viajar y a reubicarme. Facturo directamente y tengo resuelto el cobro internacional en USD. La forma más rápida de contactarme es por email.