Saltar al contenido
LR-Gutierrez

Ingeniero full-stack y líder de equipos.

Construyo software donde la seguridad es una decisión de diseño, no un checklist final.

Base
Caracas, UTC−4
Programo
Desde 2019
Estado
Abierto a remoto y relocalización
Ahora
Desarrollador senior, banca con PCI-DSS
Antes
Gerente de seguridad de la información, INAC
Stack
ASP.NET Core, NestJS, Angular, Kotlin, PostgreSQL

Trabajo seleccionado

02 proyectos

Dashboard de AuraOS: ocupación en vivo de 90 cajones, ingresos del día, membresías activas y accesos directos a sedes, salidas, modo kiosco y auditoría

Dashboard · ocupación en vivo, ingresos y accesos directos

01 · 2026

AuraOS

Control de acceso a estacionamientos local-first

Reemplaza la bitácora en papel de un estacionamiento con una app para el vigilante en ronda y un kiosco de autoservicio. Sigue funcionando sin conexión gracias a un change journal propio y merge a nivel de campo, y sincroniza con un backend NestJS y PostgreSQL; los operadores inician sesión con biometría respaldada por llaves de hardware.

  • Kotlin
  • Room
  • NestJS
  • PostgreSQL · Prisma
  • SSE · FCM
  • Android Keystore

Panel de control · órdenes, alertas de kilometraje, finanzas e inventario por período

02 · 2026

AutoNex

ERP para talleres, desde la recepción del vehículo hasta la entrega

Órdenes de servicio que registran kilometraje, nivel de combustible, daños previos y fallas reportadas; historial del vehículo por placa o VIN; inventario con control de stock mínimo; recordatorios de mantenimiento por kilometraje vía WhatsApp; y tasas oficiales del BCV extraídas, aprobadas y publicadas según calendario.

  • ASP.NET Core
  • PostgreSQL
  • Angular
  • Ionic · Capacitor
  • SignalR
  • wa-notifier · NestJS
  • Autenticación biométrica (móvil)

Cómo trabajo

La seguridad como insumo de diseño

Dirigí la seguridad de la información en la aviación civil venezolana y hoy construyo dentro de un entorno bancario PCI-DSS. La autenticación, el manejo de datos y los modos de falla se definen junto con la arquitectura, no se auditan después.

Liderar al equipo, no solo el código

He coordinado equipos de desarrollo de punta a punta: levantando requisitos con quienes usan el sistema, planificando y dando seguimiento al trabajo, e informando el avance a la dirección.

IA en el ciclo de desarrollo

Escribo Skills y servidores MCP, y oriento agentes para acelerar las partes repetitivas del ciclo, mientras las decisiones de diseño y la revisión siguen siendo mías.

  • .NET
  • NestJS
  • Laravel
  • OpenJDK
  • JSON Web Tokens
  • Angular
  • TypeScript
  • React
  • Tailwind CSS
  • Kotlin
  • Android
  • Ionic
  • PostgreSQL
  • Prisma
  • SQLite
  • Linux
  • Proxmox
  • GNU Privacy Guard
  • WhatsApp
  • Firebase

Skills

Selecciona una para ver dónde la apliqué

Backend

Frontend

Móvil

Datos

Infraestructura

Seguridad

Integraciones

IA

Liderazgo

Cada skill enlaza a un proyecto o rol donde la usé. Nada aparece sin evidencia.

Experiencia

  1. Ago 2026 – actualidadDesarrollador de software seniorP&A Asociados Gerenciales · consultoría para un banco universal, PCI-DSS
  2. Mar – Ago 2026Consultor de softwareFreelance · ERP para taller automotriz
  3. 2025 – 2026Gerente de seguridad de la informaciónINAC · procedimiento basado en GPG para intercambiar datos sensibles con entidades externas
  4. 2023 – 2024Desarrollador de softwareINAC · API REST de alta demanda con rate limiting, JWT y permisos por ruta
  5. 2023Desarrollador de softwareBolivariana de Aeropuertos
  6. 2022 – 2023Coordinador de desarrollo y sistemasInmobiliaria Nacional · lideré el equipo de desarrollo; infraestructura sobre Proxmox

Maestría en Ciberseguridad, CEUPE (previsto 2027) · Ingeniería en Informática, UNEXCA

Inglés (B2) · Ruso (A1)

Abierto a roles remotos como ingeniero senior o líder de equipo

luisangelrgr@gmail.com

01 · 2026

AuraOS

Control de acceso a estacionamientos local-first

Reemplaza la bitácora en papel de un estacionamiento con una app para el vigilante en ronda y un kiosco de autoservicio. Sigue funcionando sin conexión gracias a un change journal propio y merge a nivel de campo, y sincroniza con un backend NestJS y PostgreSQL; los operadores inician sesión con biometría respaldada por llaves de hardware.

Problema

El estacionamiento en el que se inspira funcionaba con bitácora en papel: lento en la entrada, sin historial real, y sin forma de que el vigilante marcara algo irregular. La conectividad en sitio es poco confiable, así que todo lo que se construyera tenía que seguir funcionando con la red caída.

Rol

Único desarrollador y líder en ambos lados: el cliente Android (Kotlin, MVVM, Room) y el backend NestJS/PostgreSQL. Responsable del protocolo de sincronización de punta a punta.

Restricciones

  • Offline-first: el dispositivo del vigilante tiene que seguir funcionando en zonas sin señal, sin pérdida silenciosa de datos al reconectar.
  • Sin equipo de QA — la corrección tiene que venir del modelo de datos, no de pruebas manuales.
  • Un solo desarrollador, así que el protocolo de sincronización no podía depender de que un servidor arbitrara conflictos; tenía que ser lo bastante simple como para razonarlo solo.

Decisiones clave

LWW por campo con timestamp del dispositivo

Cada campo se fusiona de forma independiente, gana la última escritura, usando el timestamp que registró el dispositivo cuando ocurrió el cambio — el servidor nunca sustituye con su propio reloj. Eso mantiene al cliente completamente capaz de trabajar offline y la lógica de merge simple. El trade-off: un dispositivo con el reloj mal puede ganarle en silencio a una edición correcta, y el DELETE se resuelve a ciegas, sin negociación si un borrado y una edición compiten. Aceptable para una bitácora de acceso, no es lo que usaría por defecto para datos financieros.

ChangeJournal de solo append

Cada mutación local se registra como una entrada inmutable y se reproduce para sincronizar, en vez de comparar estado mutable. Eso hace el protocolo de sincronización auditable y fácil de depurar offline, a costa de un journal local que crece y necesita compactación periódica — todavía no construida.

Biometría en vez de un PIN compartido

Los operadores comparten un dispositivo físico en la garita, así que un PIN terminaría siendo compartido también. El desbloqueo biométrico respaldado por llaves de hardware del Android Keystore ata cada acción a una persona, no a un dispositivo. El trade-off: cada operador tiene que enrolarse antes de su primer turno.

Arquitectura

Kotlin, MVVM y Room en el cliente; un backend NestJS y PostgreSQL (Prisma) sincronizado por SSE, con FCM para notificaciones push cuando la app no está en primer plano.

Resultado

Un prototipo funcional completo y documentado: ambas apps compilan y corren, y el protocolo de sincronización funciona de punta a punta en pruebas manuales. No se ha desplegado ni probado en condiciones reales de campo, no hay CI, y algunas pruebas están fallando actualmente — cerrar eso va antes que cualquier piloto, no después.

Qué haría distinto

Montaría un job de CI desde el primer día, aunque sea solo lint y build en cada push, en vez de dejarlo para después. Y revisaría la resolución a ciegas del DELETE antes de que esto llegue a un sitio real: un soft-delete con el conflicto expuesto explícitamente es un cambio chico ahora y uno mucho más grande una vez que haya datos reales que migrar.

Tecnologías

  • Kotlin
  • Room
  • NestJS
  • PostgreSQL · Prisma
  • SSE · FCM
  • Android Keystore